>I would be curious to get feedback from implementors of
>draft-ietf-ipngwg-icmp-name-lookups-10.txt
>on what they have implemented and what they find useful.
>
>For example, we only implement the unicast mode and not the multicast
>mode when the subject of a query is an address and we do not
>implement queries where the subject is a name, as it is completely
>redundant with LLMNR.
>
>Also, we do not implement the flag to request the now deprecated Site
>Local addresses,
>but we implement the queries for IPv4 addresses.
>
>What do other implementors do?
KAME have implemented this draft well before it became wg group item,
and always keep trying to catch up with the spec. therefore, some
portion is based on the old spec, and we have whole bunch of backward
compatibility support (like support for old packet format when Qtype
was not defined at all).
what we have implemented:
noop (Qtype=0)
supported query types (Qtype=1)
node name (Qtype=2)
node addr (Qtype=3), except IPv4 mapped address
what we have extended:
node addr (Qtype=2), flag bit for anycast address
(not sure if it is good idea, as anycast address can be
categorized as global/site-local/link-local address)
backward compatibility support for Qtype=2 response without
DNS name encoding
what we did not implement, and no plan on implmenting:
IPv4 address query (Qtype=4)
IPv4 mappped address in response (Qtype=3, C bit)
user modifyable toggles:
flag bit to decide whether or not to respond to NIQ at all
flag bit to decide whether or not to respond to NIQ to
RFC3041 address
flag bit to decide whether or not to respond to node addresses
NIQ (Qtype=2) - we may not want to reveal address on
other interfaces when A bit is present, like intranet
side of firewall machine
what we see as "frills" (should be removed in -11):
any IPv4 stuff
site-local (Qtype=3, S bit)
noop (Qtype=0), maybe - "anycast address" text in 6.1 looks
a bit useful
we think multicast portion is the most important of all usage, i.e.
to learn link-local address of peer on a p2p link. this is the most
important usage in our debugging situations.
(i.e. discover neighbor when routing protocol goes mad)
A -p2p-- B
-----> NIQ, Qtype=1 to ff02::1
<----- NI reply with source address (fe80::B) and name
another usage is to know the name of the machine which is sending rogue
RA (this happens too many times in conference environment).
admin rogue router
| |
==+===============+==
-----> NIQ, Qtype=1 to ff02::2 (or fe80::rogue)
<----- NI reply with source address and name
>Last but not least, we implement it also over ICMPv4 (not defined in
>the spec yet).
KAME does not do it.
itojun
PS: KAME folks, any clarifications/corrections are requested.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
