home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
addrconf
/
addrconf-minutes-95jul.txt
< prev
next >
Wrap
Text File
|
1995-10-18
|
5KB
|
129 lines
CURRENT_MEETING_REPORT_
Reported by Susan Thomson/Bellcore
Minutes of the Address Autoconfiguration Working Group (ADDRCONF)
The ADDRCONF Working Group met once at the 33rd IETF on Wednesday, 19
July. (A second session had been scheduled, but the group finished all
work before the end of the first session.) Sue Thomson lead the
meeting.
Specification Review
Sue reviewed the changes made to the specification since the Danvers
IETF meeting in April. This included the work done at the interim
meeting of the working group that was held in July.
The review brought up a couple of items for discussion:
o In order to be usable by a host, the address prefix provided by the
router must be short enough to accommodate the link-specific token.
That is, the prefix must be equal to 128 minus the length of the
link-specific token.
The question was raised whether routers should be allowed to
advertise prefixes that are shorter than the length required to
accommodate the link-specific token, and have the host pad the gap
with zeroes. It was argued that the configuration management
interface on the router could zero-fill the prefixes just as well,
and avoid situations where the same prefix with different lengths
is advertised by a router.
o Default values for the timers in the protocol were discussed.
There was general agreement that the following values are ok:
- Invalidate timer: infinity
- Deprecate timer: one week
Link Initialization
Next, Sue walked through the steps of link initialization:
1. Form a link-local address.
2. Join the all-nodes multicast address.
3. Join the solicited-nodes multicast address.
4. Dither.
5. Send a neighbor solicitation for the link-local address.
6. Expect to receive solicitation looped back from the local network
interface driver -- drop it when received.
7. Wait to receive packets.
7a. If second solicitation for the link-local address is received,
another node is preparing to use that address (a duplicate has been
detected).
7b. If a neighbor advertisement for the link-local address is received,
another node is using that address (a duplicate has been detected).
8. Send a router solicitation.
This lead to discussion of a number of issues:
o Duplicate address detection. The specification includes a section
explaining how a node can detect when an address generated using
stateless address autoconfiguration is being used by another node.
Some people felt that nodes should not be required to perform
duplicate address detection since the failure case is quite rare
and the cost to implement is non-trivial. Others argued that,
while cases of duplicate addresses might be extremely unusual, they
are extremely difficult for network administrators to diagnose and
remedy when they do occur.
After quite a bit of discussion, there was general agreement that
duplicate address detection should be required for link-local
addresses, and any address not based on the link-specific token.
o Silently discard first duplicate solicitation. In the duplicate
detection algorithm, a node is required to discard the first
duplicate solicitation message for its own address that it
receives. This is done because of the assumption that the network
interface driver may loop back (deliver locally) the first
solicitation that the node sends. Some people objected to this
language, arguing that it was an implementation issue whether the
driver loops back the solicitation packet. Others argued that the
IP layer may not be able to disable the loopback at the driver
level, so the safest thing to do is to enable loopback and expect
one duplicate.
o Serial-link hubs (e.g., PPP dial-in hubs). The issue of whether
the specification should attempt to address the case of serial-link
hubs was brought up. There was general agreement that this issue
should be covered in the IPv6 over PPP specification document, and
not in the address autoconfiguration specification.
o Automatic resolution of duplicate addresses. The specification
states only that a host should log the event when a duplicate is
detected and stop using the address. Some suggested that the
specification might be able to specify a mechanism by which the
duplicate address could be resolved, allowing both hosts to
continue functioning. But no proposal was offered for such a
mechanism, so the group agreed to leave the specification as is.
The Next Revision
Finally, the group discussed whether the specification should be moved
forward to Proposed Standard after another revision of the draft. It
was agreed that the next version of the document should contain more
explicit text on the interface initialisation procedure (perhaps in an
Appendix). Also, the time that the host is determined to be in address
validation mode needs to begin as soon as the host has formed its
link-local address, rather than after first sending out the Neighbor
Solicitation.