Skip to main content

IPv6 Node Information Queries
RFC 4620

Revision differences

Document history

Date Rev. By Action
2015-10-14
15 (System) Notify list changed from <bob.hinden@nokia.com> to (None)
2012-08-22
15 (System) post-migration administrative database adjustment to the No Objection position for Allison Mankin
2012-08-22
15 (System) post-migration administrative database adjustment to the No Objection position for David Kessens
2006-08-10
15 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2006-08-10
15 Amy Vezza [Note]: 'RFC 4620' added by Amy Vezza
2006-08-09
15 (System) RFC published
2006-03-23
15 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-03-13
15 Amy Vezza IESG state changed to Approved-announcement sent
2006-03-13
15 Amy Vezza IESG has approved the document
2006-03-13
15 Amy Vezza Closed "Approve" ballot
2006-03-12
15 Margaret Cullen State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Margaret Wasserman
2006-03-10
15 (System) [Ballot Position Update] New position, No Objection, has been recorded for Ned Freed
2006-03-10
15 (System) [Ballot Position Update] Position for Steven Bellovin has been changed to Discuss from No Record
2006-03-10
15 (System) [Ballot Position Update] New position, Discuss, has been recorded for Jeffrey Schiller
2006-03-10
15 (System) [Ballot Position Update] New position, Yes, has been recorded for Thomas Narten
2006-03-10
15 (System) [Ballot Position Update] Position for Randy Bush has been changed to Discuss from No Record
2006-03-10
15 (System) [Ballot Position Update] New position, No Objection, has been recorded for Patrik Faltstrom
2006-03-10
15 (System) [Ballot Position Update] New position, Yes, has been recorded for Scott Bradner
2006-03-10
15 (System) [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand
2006-03-10
15 (System) [Ballot Position Update] New position, Discuss, has been recorded for Erik Nordmark
2006-03-10
15 David Kessens [Ballot Position Update] Position for David Kessens has been changed to No Objection from Discuss by David Kessens
2006-03-03
15 David Kessens
[Ballot discuss]
This DISCUSS is also a placeholder for some questions that IANA has regarding this draft:

---
For draft-ietf-ipngwg-icmp-name-lookups-15.txt, I have a some …
[Ballot discuss]
This DISCUSS is also a placeholder for some questions that IANA has regarding this draft:

---
For draft-ietf-ipngwg-icmp-name-lookups-15.txt, I have a some questions.       
I'm going to try to get these questions to you by the end of today.           
Can you please hold this for IANA until I get these questions to you? 

Michelle                                                                       
IANA
---

My own DISCUSS text follows below:

I believe the following comments warrant a brief discussion. My intention is
not to hold this document. Instead, I would like to know whether the authors
have considered the following comments and whether they are really sure that
they want to go this route instead of keeping things more simple.

I received the following comments by Ólafur Guðmundsson <ogud@ogud.com> from
the DNS review team:

This document looks fine, from DNS perspective. It's main role is             
on local link and for debugging.                                               
My comments on the document:                                                   
1. The document assumes local names are only one DNS label ie node can         
  not be named "apple.printer" or "b32.switch". the rule for how non         
  fully qualified names are terminated is strange (two 0 labels).             
2. The document recommends DNS name compression when there are multiple       
names.                                                                         
  No feature of DNS has caused more problems than name compression, so       
  earlier in the process I would have argued hard for having this removed,   
  all it does is add complexity and errors, and the savings in packet size   
  are not significant. Unless there are 10+ names and all in the same         
  domain.                                                                     
  (this falls into my category optimization-is-evil when the payoff is       
    not likely to reduce the number of packets sent).
2006-03-03
15 (System) Removed from agenda for telechat - 2006-03-02
2006-03-02
15 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2006-03-02
15 David Kessens
[Ballot discuss]
This DISCUSS is also a placeholder for the IANA considerations.

My own DISCUSS text follows below:

I believe the following comments warrant a …
[Ballot discuss]
This DISCUSS is also a placeholder for the IANA considerations.

My own DISCUSS text follows below:

I believe the following comments warrant a brief discussion. My intention is
not to hold this document. Instead, I would like to know whether the authors
have considered the following comments and whether they are really sure that
they want to go this route instead of keeping things more simple.

I received the following comments by Ólafur Guðmundsson <ogud@ogud.com> from
the DNS review team:

This document looks fine, from DNS perspective. It's main role is             
on local link and for debugging.                                               
My comments on the document:                                                   
1. The document assumes local names are only one DNS label ie node can         
  not be named "apple.printer" or "b32.switch". the rule for how non         
  fully qualified names are terminated is strange (two 0 labels).             
2. The document recommends DNS name compression when there are multiple       
names.                                                                         
  No feature of DNS has caused more problems than name compression, so       
  earlier in the process I would have argued hard for having this removed,   
  all it does is add complexity and errors, and the savings in packet size   
  are not significant. Unless there are 10+ names and all in the same         
  domain.                                                                     
  (this falls into my category optimization-is-evil when the payoff is       
    not likely to reduce the number of packets sent).
2006-03-02
15 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2006-03-02
15 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2006-03-01
15 David Kessens
[Ballot discuss]
I believe the following comments warrant a brief discussion. My intention is
not to hold this document. Instead, I would like to know …
[Ballot discuss]
I believe the following comments warrant a brief discussion. My intention is
not to hold this document. Instead, I would like to know whether the authors
have considered the following comments and whether they are really sure that
they want to go this route instead of keeping things more simple.

I received the following comments by Ólafur Guðmundsson <ogud@ogud.com> from
the DNS review team:

This document looks fine, from DNS perspective. It's main role is             
on local link and for debugging.                                               
My comments on the document:                                                   
1. The document assumes local names are only one DNS label ie node can         
  not be named "apple.printer" or "b32.switch". the rule for how non         
  fully qualified names are terminated is strange (two 0 labels).             
2. The document recommends DNS name compression when there are multiple       
names.                                                                         
  No feature of DNS has caused more problems than name compression, so       
  earlier in the process I would have argued hard for having this removed,   
  all it does is add complexity and errors, and the savings in packet size   
  are not significant. Unless there are 10+ names and all in the same         
  domain.                                                                     
  (this falls into my category optimization-is-evil when the payoff is       
    not likely to reduce the number of packets sent).
2006-03-01
15 David Kessens [Ballot Position Update] New position, Discuss, has been recorded for David Kessens by David Kessens
2006-03-01
15 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2006-03-01
15 Allison Mankin
[Ballot comment]
The response to my Discuss issues was full.  I'm also see the Security
Considerations as having good knobs for controlling information exposure
and …
[Ballot comment]
The response to my Discuss issues was full.  I'm also see the Security
Considerations as having good knobs for controlling information exposure
and privacy (responding to the departed ADs' Discusses).  I cleared with
good will.

Bob Hinden's responses to my Discuss:

> My particular concern: there should be much less extensibility.
> I think it would be reasonable to have a small space for
> RFC approved new queries and a small space for private use,
> and that's all.

The current draft is less extensible and only allows new types by
IETF consensus.  From Section 7. IANA Considerations:

    This document defines five values of Qtype, numbers 0 through 4.
    Following the policies outlined in [16], new values, and their
    associated Flags and Reply Data, are to be defined by IETF
    Consensus.

> Also a question: what happens if you send a query for node
> address to the multicast address - what is the target?

In the case of multicast, the query is only processed if the
destination address was sent to a link-local scope multicast address
that the node had joined.  From Section 5 "Message Processing", fifth
paragraph:

    Upon receiving an NI Query, the Responder must check the
    Query's IPv6
    destination address and discard the Query without further processing
    unless it is one of the Responder's unicast or anycast addresses, or
    a link-local scope multicast address which the Responder has joined.
    Typically the latter will be an NI Group Address for a name
    belonging
    to the Responder.  A node MAY be configured to discard NI Queries to
    multicast addresses other than its NI Group Address(es) but if so,
    the default configuration SHOULD be not to discard them.

Also, the last paragraph of the same section:

    If the Query was sent to a multicast address, transmission of the
    Reply MUST be delayed by a random interval between zero and [Query
    Response Interval], as defined by Multicast Listener Discovery
    Version 2 [10].

> Overall I support others views that a very simple version of
> this is of value (as it is used by KAME, e.g.).

This is what is used by KAME (except for the change of multicast
address assignments as describe in the questionnaire).
2006-03-01
15 Allison Mankin
[Ballot comment]
The response to my Discuss issues was full.  I'm also see the Security
Considerations as having good knobs for controlling information exposure
and …
[Ballot comment]
The response to my Discuss issues was full.  I'm also see the Security
Considerations as having good knobs for controlling information exposure
and privacy (responding to the departed ADs' Discusses).  I cleared with
good will.

Bob Hinden's responses to my Discuss:

> My particular concern: there should be much less extensibility.
> I think it would be reasonable to have a small space for
> RFC approved new queries and a small space for private use,
> and that's all.

The current draft is less extensible and only allows new types by
IETF consensus.  From Section 7. IANA Considerations:

    This document defines five values of Qtype, numbers 0 through 4.
    Following the policies outlined in [16], new values, and their
    associated Flags and Reply Data, are to be defined by IETF
Consensus.

> Also a question: what happens if you send a query for node
> address to the multicast address - what is the target?

In the case of multicast, the query is only processed if the
destination address was sent to a link-local scope multicast address
that the node had joined.  From Section 5 "Message Processing", fifth
paragraph:

    Upon receiving an NI Query, the Responder must check the Query's
IPv6
    destination address and discard the Query without further processing
    unless it is one of the Responder's unicast or anycast addresses, or
    a link-local scope multicast address which the Responder has joined.
    Typically the latter will be an NI Group Address for a name
belonging
    to the Responder.  A node MAY be configured to discard NI Queries to
    multicast addresses other than its NI Group Address(es) but if so,
    the default configuration SHOULD be not to discard them.

Also, the last paragraph of the same section:

    If the Query was sent to a multicast address, transmission of the
    Reply MUST be delayed by a random interval between zero and [Query
    Response Interval], as defined by Multicast Listener Discovery
    Version 2 [10].

> Overall I support others views that a very simple version of
> this is of value (as it is used by KAME, e.g.).

This is what is used by KAME (except for the change of multicast
address assignments as describe in the questionnaire).
2006-03-01
15 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Discuss by Allison Mankin
2006-03-01
15 Ted Hardie
[Ballot comment]
I think this is okay for Experimental, but i frankly can't see it ever making the transition to standards track without a very …
[Ballot comment]
I think this is okay for Experimental, but i frankly can't see it ever making the transition to standards track without a very restrictive applicability statement .  The work makes quite a few assumptions about the environment of use that seem unlikely, and its security properties give me the chills.  In a debugging environment, I can see some usefulness, but even in a serverless environment I think the risk vs. reward is skewed.
2006-03-01
15 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2006-03-01
15 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2006-02-24
15 Margaret Cullen [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman
2006-02-24
15 Margaret Cullen Ballot has been issued by Margaret Wasserman
2006-02-24
15 (System) Ballot writeup text was added
2006-02-24
15 (System) Last call text was added
2006-02-24
15 (System) Ballot approval text was added
2006-02-17
15 Margaret Cullen [Note]: 'The PROTO Shepherd is Bob Hinden <hinden@nokia.com>.' added by Margaret Wasserman
2006-02-17
15 Margaret Cullen State Change Notice email list have been change to <bob.hinden@nokia.com> from <bob.hinden@nokia.com>, <mrw@windriver.com>
2006-02-17
15 Margaret Cullen Placed on agenda for telechat - 2006-03-02 by Margaret Wasserman
2006-02-17
15 Margaret Cullen State Changes to IESG Evaluation from AD Evaluation by Margaret Wasserman
2006-02-17
15 Margaret Cullen Intended Status has been changed to Experimental from Proposed Standard
2006-02-17
15 Margaret Cullen State Changes to AD Evaluation from AD is watching::AD Followup by Margaret Wasserman
2006-02-17
15 Margaret Cullen
Questionnaire below.  Bob Hinden will be the shepherding chair.

Bob Hinden & Brian Haberman
IPv6 chairs

------------

>    1.a) Have the chairs personally reviewed …
Questionnaire below.  Bob Hinden will be the shepherding chair.

Bob Hinden & Brian Haberman
IPv6 chairs

------------

>    1.a) Have the chairs personally reviewed this version of the
> Internet
>        Draft (ID), and in particular, do they believe this ID is
> ready
>        to forward to the IESG for publication?
>

Yes.


>    1.b) Has the document had adequate review from both key WG members
>        and key non-WG members?  Do you have any concerns about the
>        depth or breadth of the reviews that have been performed?
>

Yes.  This document has been reviewed and commented on by many people in the working group.

>
>    1.c) Do you have concerns that the document needs more review 
> from a
>        particular (broader) perspective (e.g., security, operational
>        complexity, someone familiar with AAA, etc.)?
>

No.


>    1.d) Do you have any specific concerns/issues with this document 
> that
>        you believe the ADs and/or IESG should be aware of?  For
>        example, perhaps you are uncomfortable with certain parts 
> of the
>        document, or have concerns whether there really is a need for
>        it.  In any event, if your issues have been discussed in 
> the WG
>        and the WG has indicated it that it still wishes to advance 
> the
>        document, detail those concerns in the write-up.
>

No.



>    1.e) How solid is the WG consensus behind this document? Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?
>

The working group as a whole understands and agrees with the document.


>    1.f) Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email to the Responsible Area Director.
>

No.


>    1.g) Have the chairs verified that the document adheres to all 
> of the
>        ID nits? (see http://www.ietf.org/ID-Checklist.html).
>

Yes.

>
>    1.h) Is the document split into normative and informative 
> references?
>        Are there normative references to IDs, where the IDs are not
>        also ready for advancement or are otherwise in an unclear 
> state?
>        (note here that the RFC editor will not publish an RFC with
>        normative references to IDs, it will delay publication 
> until all
>        such IDs are also ready for publication as RFCs.)
>

Yes.  All normative references are either RFC or in the RFC-editor 
queue.

>
>    1.i) For Standards Track and BCP documents, the IESG approval
>        announcement includes a write-up section with the following
>        sections:
>
>        *    Technical Summary
>
>        *    Working Group Summary
>
>        *    Protocol Quality
>

This was submitted for experimental.  However,

Technical Summary

    This document describes a protocol for asking an IPv6 node to supply
    certain network information, such as its hostname or fully-qualified
    domain name.  IPv6 implementation experience has shown that direct
    queries for a hostname are useful, and a direct query mechanism for
    other information has been found useful in serverless environments
    and for debugging.

Working Group Summary

    The latest specification does differ from what is currently 
deployed.
    Reviews revealed that the multicast prefix used by the Node Info
    Queries does not conform to the requirements of RFC 3307.  The
    editors corrected the oversight within the specification to ensure
    proper operation over the long-term.  Those who have already
    implemented the protocol agreed with the change and plan on
    updating their code to conform to the new multicast prefix.

    Other minor changes were made to address deprecated functionality
    that no longer needs to be supported (e.g. IPv4-compatible addresses
    and site-local addresses).

Protocol Quality

    IPv6 Node Information Queries have been widely implemented in the 
ping6
    program in the KAME (<http://www.kame.net>), USAGI, and other IPv6
    implementations.  It is proved to be very useful when
    debugging problems or when bringing up IPv6 service where there 
isn't
    global routing or DNS name services available.  IPv6's large auto-
    configured addresses make debugging network problems and bringing up
    IPv6 service difficult without these mechanisms.

>
2006-02-17
15 Margaret Cullen Note field has been cleared by Margaret Wasserman
2006-02-17
15 Dinara Suleymanova
PROTO Write-up

1.a) Have the chairs personally reviewed this version of the
Internet Draft (ID), and in particular, do they believe this ID is
ready …
PROTO Write-up

1.a) Have the chairs personally reviewed this version of the
Internet Draft (ID), and in particular, do they believe this ID is
ready to forward to the IESG for publication?

Yes.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

Yes. This document has been reviewed and commented on by many people
in the working group.

1.c) Do you have concerns that the document needs more review
from a particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No.

1.d) Do you have any specific concerns/issues with this document
that you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts
of the document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in
the WG  and the WG has indicated it that it still wishes to advance
the  document, detail those concerns in the write-up.

No.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The working group as a whole understands and agrees with the document.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.

No.

1.g) Have the chairs verified that the document adheres to all
of the
ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

1.h) Is the document split into normative and informative
references? Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear
state? (note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication
until all such IDs are also ready for publication as RFCs.)

Yes. All normative references are either RFC or in the RFC-editor
queue.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

* Working Group Summary

* Protocol Quality

This was submitted for experimental. However,

Technical Summary

This document describes a protocol for asking an IPv6 node to supply
certain network information, such as its hostname or fully-qualified
domain name. IPv6 implementation experience has shown that direct
queries for a hostname are useful, and a direct query mechanism for
other information has been found useful in serverless environments
and for debugging.

Working Group Summary

The latest specification does differ from what is currently
deployed. Reviews revealed that the multicast prefix used by the Node Info
Queries does not conform to the requirements of RFC 3307. The
editors corrected the oversight within the specification to ensure
proper operation over the long-term. Those who have already
implemented the protocol agreed with the change and plan on
updating their code to conform to the new multicast prefix.

Other minor changes were made to address deprecated functionality
that no longer needs to be supported (e.g. IPv4-compatible addresses
and site-local addresses).

Protocol Quality

IPv6 Node Information Queries have been widely implemented in the
ping6 program in the KAME (<http://www.kame.net>), USAGI, and other IPv6
implementations. It is proved to be very useful when
debugging problems or when bringing up IPv6 service where there
isn't global routing or DNS name services available. IPv6's large auto-
configured addresses make debugging network problems and bringing up
IPv6 service difficult without these mechanisms.
2006-02-14
15 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-15.txt
2006-02-03
14 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-14.txt
2006-01-31
15 Mark Townsley Shepherding AD has been changed to Margaret Wasserman from Mark Townsley
2006-01-31
15 Mark Townsley Shepherding AD has been changed to Mark Townsley from Thomas Narten
2006-01-04
13 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-13.txt
2005-08-18
15 Randy Bush
[Ballot discuss]
Discuss comment transferred from old ballot:

extremely vulnerable to many kinds of attacks, e.g. adress spoofing.

---

just when we have dnssec heading …
[Ballot discuss]
Discuss comment transferred from old ballot:

extremely vulnerable to many kinds of attacks, e.g. adress spoofing.

---

just when we have dnssec heading for the door, along comes nice
totally insecure reverse lookup.

---

despite saying

        In the global internet, the Domain Name System [1034, 1035]
  is the authoritative source of such information and this
        specifcation is not intended to supplant or supersede it.

the folk in the wg admitted that this is part of the exceedingly
underspecified serverless architecture, i.e. meant to replace
dns.

i.e. dig this

The Querier constructs an ICMP NI Query and sends it to the
address from which information is wanted. When the Subject of the
Query is an IPv6 address, that address will normally be used as
the IPv6 destination address of the Query, but need not be if the
Querier has useful a priori information about the addresses of
the target node. An NI Query may also be sent to a multicast
address of link-local scope [2373].

      When the Subject is a name, either fully-qualified or single-
      component, and the Querier does not have a unicast address for
the target node, the query MUST be sent to a link-scope multicast
      address formed in the following way. The Subject Name is
converted to the canonical form defined by DNS Security [2535],
which is uncompressed with all alphabetic characters in lower
case. (If additional DNS label types for host names are created,
the rules for canonicalizing those labels will be found in their
defining specification.) Compute the MD5 hash [1321] of the first
label of the Subject Name -- the portion beginning with the first
one-octet length field and up to, but excluding, any subsequent
length field. Append the first 32 bits of that 128-bit hash to
  the prefix FF02:0:0:0:0:2::/96. The resulting multicast address
will be termed the "NI Group Address" for the name.

so i suggest that this could be a dns end-run and hence needs
review in dnsext. though this may not be the best time to get calm
adult review in that wg.

---

the icmp types
        Type 139 - NI Query.
                                140 - NI Reply.
are claimed to already be assigned for this protocol. i wonder how.

---

5.1. NOOP

This NI type has no defined flags and never has a Data field.
A Reply to a NI NOOP Query tells the Querier that a node with
the Queried Address is up and reachable, implements the Node
      Information protocol, and incidentally happens to reveal
whether the Queried Address was an anycast address.

the whole subject of whether an anycast address should be
differentiable is, or should be, undecided.

---

The compressed form of the Reply Data consists of a sequence
of blocks, each block consisting of two 16-bit unsigned
integers, nWord and nSkip, followed by nWord 32-bit bitmasks
describing the Responder's support for 32 consecutive Qtypes.
nSkip is a count of 32-bit words following the included words
which would have been all-zero and have been suppressed. The
last block MUST have nSkip = 0. As an example, a Responder
supporting Qtypes 0, 1, 2, 3, 60, and 4097 could express that
information with the following Reply Data (nWord and nSkip
fields are written in decimal for easier reading):

how clever, and i do not mean that as a compliment. just how many
qtypes does this intend?

---

someone else already caught the TTL strangeness

---

a6 resource records, now deprecated, are supported.

---

this one is really cool

If the Query was sent by a DNS server on behalf of a DNS
      client, the result may be returned to that client as a DNS
      response with TTL zero.

so does the server return ad-is-secure to a stub resolver in this
case? :-)

oh, and note that this paragraph and the one following make it
quite clear that this is meant to be part of the dns or a
replacement for part of it.

---

and also

Because a node can only answer a Node Name Request when it is
      up and reachable, it may be useful to create a proxy responder
      for a group of nodes, for example a subnet or a site.

---

since it is replacing the dns, it is good that it handles ipv4
addresses as well.

---

there is nothing keeping these queries local or limiting them to
zeroconf environments.

-30-

Jeff:
Many application implementations do a reverse DNS lookup on an IP
address to learn the DNS Name of the connecting system. This name
is then used to make access control decisions. Some may believe that
this mechanism can be used to replace the reverse lookup. However
this introduces a new security vulnerability, which is to say that
a bogus host could connect to a service and when queried with this
protocol it would provide the DNS Name that the server is expecting
and therefore make an inappropriate access control decisions.

The Security Considerations section should have words in it to the
effect that the FQDN information (and other information) provided
cannot be trusted for making security relevant decisions unless
some other mechanism beyond the scope of this document is used to
authenticate that information.
2005-08-18
15 Steven Bellovin
[Ballot discuss]
Discuss comment transferred from old ballot:

5.3 How can a DNS TTL be returned? TTLs depend on the original
        …
[Ballot discuss]
Discuss comment transferred from old ballot:

5.3 How can a DNS TTL be returned? TTLs depend on the original
        value and how long it's been since an authoritative server
          sent out the information. Besides, how does a typical
          kernel (the entity that usually processes ICMP messages)
          know anything about DNS replies or dhcp lease time? I can
          imagine a DHCP client installing the current lease
          expiration every time it does a rebind or renew, but on what
    basis should a host do DNS queries? I think the "use once"
    semantics mentioned are far better.
 
                The document speaks of A6. Should it?
 
5.4 It speaks of truncation for space reasons. How large can
                the reply be?
2005-08-17
15 Allison Mankin
[Ballot discuss]
Discuss transferred from old style text ballot:
My particular concern: there should be much less extensibility.
I think it would be reasonable to …
[Ballot discuss]
Discuss transferred from old style text ballot:
My particular concern: there should be much less extensibility.
I think it would be reasonable to have a small space for
RFC approved new queries and a small space for private use,
and that's all.

Also a question: what happens if you send a query for node
address to the multicast address - what is the target?

Overall I support others views that a very simple version of
this is of value (as it is used by KAME, e.g.).
2005-08-17
15 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Amy Vezza
2005-08-17
15 Amy Vezza [Ballot Position Update] New position, Discuss, has been recorded for Allison Mankin by Amy Vezza
2005-08-17
15 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Amy Vezza
2005-08-17
15 Amy Vezza Created "Approve" ballot
2005-07-14
15 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-07-14
12 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-12.txt
2005-05-06
11 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-11.txt
2003-06-27
10 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-10.txt
2003-06-23
15 Thomas Narten IESG comments sent to WG June, 2002. WG hasn't decided what to do.
2003-06-23
15 Thomas Narten State Changes to AD is watching  :: Revised ID Needed from IESG Evaluation  :: Revised ID Needed by Narten, Thomas
2002-10-04
15 Thomas Narten State Changes to IESG Evaluation  -- New ID Needed from IESG Evaluation  -- Point Raised - writeup needed by narten
2002-06-14
15 Stephen Coya Due date has been changed to 06/13/2002 from 06/06/2002<br>by scoya
2002-06-14
15 Stephen Coya responsible has been changed to Narten from Unassigned
2002-06-14
15 Stephen Coya
State Changes to Evaluation: Discuss                              from Ready for Telechat      …
State Changes to Evaluation: Discuss                              from Ready for Telechat                                by scoya
2002-06-09
15 Stephen Coya
State Changes to Ready for Telechat                                from Last Call Issued  …
State Changes to Ready for Telechat                                from Last Call Issued                                  by scoya
2002-05-23
15 Jacqueline Hargest Due date has been changed to 06/06/2002 from 09/13/2001<br>by jhargest
2002-05-23
15 Jacqueline Hargest
State Changes to Last Call Issued                                  from New Version …
State Changes to Last Call Issued                                  from New Version Needed (WG/Author)                    by jhargest
2002-05-23
15 (System) Last call sent
2002-05-20
09 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-09.txt
2002-04-23
15 Thomas Narten Needs applicability statement to position it relative to using PTR records
2002-04-23
15 Thomas Narten
State Changes to New Version Needed (WG/Author)                    from Wait for Writeup            …
State Changes to New Version Needed (WG/Author)                    from Wait for Writeup                                  by Thomas Narten
2001-07-24
08 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-08.txt
2000-08-29
07 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-07.txt
2000-07-20
06 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-06.txt
1999-10-26
05 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-05.txt
1999-06-22
04 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-04.txt
1999-03-03
03 (System) New version available: draft-ietf-ipngwg-icmp-name-lookups-03.txt