Editor's note: These minutes have not been edited.
Date: Wed, 18 Oct 1995 12:12:12 -0700
From: "Robert M. Hinden" <hinden@walnut.ipsilon.com>
IPng/AddrConf Working Groups Interim Meeting
October 11 & 12 1995
Dyncorp, Arlington, VA
Minutes produced by Robert Hinden / Ipsilon Networks
--------------------------------------
Attendees:
Steve Deering / Xerox PARC
Robert Hinden / Ipsilon
Thomas Narten / IBM
Erik Nordmark / Sun
Alex Conta / Digital
Dan McDonald / NRL
Tim Hartnick / Mentat
Gaetan Feige / ISI
Bob Gilligan / Sun
Scott Behnke / Dyncorp
Richard Colella / NIST
Steve Silverman / BTNA
Rob Glenn / NIST
Peter Grehan / Ipsilon
Sue Thompson / Bellcore
Jim Bound / Digital
Dan Harrington / Digital
Allison Mankin / ISI
Matt Thomas / Digital
--------------------------------------
Agenda
o Administrivia
Introductions
Note Taker
Chairship
videotaping
Document Status
o IPv6 Payload Header
o AddrConf
Discussion of Latest Specifications
o Neighbor Discovery
o IP over Foo Documents
o "IGMP" for link local multicasts
--------------------------------------------------------------------
Wednesday, October 11, 1995
--------------------------------------------------------------------
The meeting was hosted by Scott Behnke / Dyncorp and Allison Mankin / ISI.
Robert Hinden agreed to take notes for the meeting.
Steve Deering announced that Ross Callon was stepping down and Robert
Hinden will be the new co-chair (and continue to be document editor).
Steve Deering reviewed standards status. Base specification, address architecture,
ICMP, and DNS specifications were approved by IESG to be Proposed Standards.
Provider assignment architecture was approved for informational.
All are being submitted to RFC editor to become RFC's.
IETF last call being done for NSAP doc. Working group last call
completed for Provider Formats and Test Allocations addressing drafts.
No comments on Test Alloc. Only discussion on Provider Based was if
it should be Informational, BCP, or PS.
This Issue was discussed. Group agreed that Provider doc should be
advanced as a Proposed Standard. Chairs will send note to IESG
requesting these docs be advanced w/ cc to working group.
----------------------------------------------------------------------
IPv6 Payload Header
----------------------------------------------------------------------
Discussion on "The IPv6 Payload Header" draft. It would be used to
identify how multiple headers (e.g., more than one TCP header) could
be combined in one IPv6 packet. Issue raised that might be hard to
implement if several non-related headers were included. It would have
to be required to be implemented by everyone to be useful. Discussion
of benefits and costs. There does not appear to be any commercial
implementations of TMUX (somewhat similar for IPv4). There does not be
enough support in w.g. to advance this to the IESG at this time.
Members of working group should review this document and comment if
there is interest. At this time there is not enough motivation to
require this to be required for universal implementation. Suggestion
also made for some implementation experience before considering this
for advancement to become a standard. Most people have not read the draft,
not much interest, author will have to make a better case.
----------------------------------------------------------------------
Addr Conf
----------------------------------------------------------------------
Sue Thomson / Thomas Narten (gave presentation)
Open Issues:
o Duplicate address detection
o Loop back semantics
o Changing "AutoConfig" flag on running systems
o Terminology for MAC address
o Node vs. Router
o Configurability of "DuplAddrDetect"
o Separate ICMP Message for AddrConf and ND
-------
Strength of Duplicate address detection
Discussion of sending out single packet or retransmission. Most
people thought only single NS was enough. It would be nice to not
delay booting waiting for an answer. Current implementations of
duplicate detection in IPv4 (using ARP) do not wait. However, if
duplicate addresses are present, immediate use causes problems for
existing interfaces using the same address. Waiting for DAD to
complete avoids this problem.
Suggestion for different modes of operation depending on type of
address (autoconfigured addresses, dynamically assigned, manually
assigned).
Suggestion for sending one NS packet, waiting a short period of time
(one second) for duplicate. Pick generic default for Addrconf and
allow specific IPoverFoo documents to set new default value for a
particular media.
Group agreed that default behavior should be to send single NS packet,
and wait for 1 second to detect duplicates, and that these values be
configurable. A specific IPoverFoo document could define a link
specific value to change default values. The number of
retransmissions is also link type specific. [See later discussion]
Discussion of how much random delay before sending NS. The current
value is 3 sec, which is larger than the random delay used before
sending out a RS in ND. One of the differences is that all nodes will
send an NS, whereas nodes will desist from sending an RS on hearing a
RA.
-------
Discussion of whether hosts can do duplicate detection and router
discovery in parallel (or does it have to be sequential). Parallel
is preferred, since it reduces time before normal operation can start,
but requires that RAs are solicited using the unspecified address and
that RAs are multicast. [See later discussion]
--------
Configurability of Duplicate Address Detection Flag
Currently per interface configuration flag.
Change text to require duplicate detection of link local address.
Other addresses derived using this, do not need to be checked for
duplicates. (This avoids the problem in stateless autoconfiguration
of having different interfaces choose different addresses to apply
duplicate address detection to.) Duplicate detection required for all
stateful and manually configured addresses.
Instead of having this flag, there are now two per interface variables
to do with duplicate address detection. First variable indicates how
many times a solicitation is sent for duplicate detection. Second is
timer value for interval between retransmissions. Default values are
1 transmission, and 1 second. Duplicate address detection is disabled
by setting first value to zero.
Hence, no need for separate "Duplicate address detection flag"
--------
Semantics of Multicast loopback
The current text looks OK. One further thing to consider though.
Loopback is undesirable for general multicast applications. Thus, IPv4
multicast specification requires that driver suppress loopback. If not possible
to disable hardware, driver software needs to filter out loopback
multicast packets. If this filtering is done by comparing the source
address of the packet with that of the interface, i.e. dropping
packets whose link-layer source address is the same as that of the
interface, then this breaks DAD in the case where duplicate addresses
result from duplicate interface tokens (e.g., two interfaces both
using the same link-layer address).
Prefer interface to not loopback multicast packets. Approach should
be to configure hardware to not loopback, or have driver (in software)
detect duplicates with a mechanisms other than looking at the source
address. If the two previous are not possible, then a trade-off needs
to be made: allow loopback (allows duplicate address detection to
work, but inefficient in terms of multicast interrupts) or suppress
loopback by comparing source address of incoming packet and interface
(reduces number of interrupts, but disables duplicate address
detection). It is possible that an implementation might make loopback
suppression configurable in this case, i.e. only turn it on when
duplicate address detection done.
Agreed that text will be added to document explaining the problem, but
leave as an implementation issue how resolved.
----------
"AutoConfig" Flag
What happens if flag turned off and on in running system? Should
addresses from previous incarnations be kept until they time out, or
should address list be reinitialized each time flag turned on?
Discussion leading to conclusion that this should be an
implementation issue.
Discussion of what "AutoConfig" flags means. First, should the flag
apply to formation of the link-local address? There was agreement
that it should not. That is, the link-local address is always formed.
The implication of this decision is that there needs to be a way for
the token to be configurable, in the (rare) case, when the token is
found not to be unique. Suggestion for advice in IPoverFoo specs for
what to do if duplicate is detected.
Second, what part of Router Advertisements should the "AutoConfig"
flag apply to, just stateless auto-generation of global or site-local
addresses or all autoconfiguration information in router
advertisements? What does flag say about using stateful mechanism in
absence of RAs?
One suggestion was that the "AutoConfig" Flag should only refer to the
automatic creation of addresses and bit flags telling hosts to use
DHCP (e.g., ignore this information in router advertisements). Other
functions not affected (e.g., duplicate detection, link local, router
discovery, routing prefixes, etc.)
Another suggestion was for two independent flags, one for disabling
stateless and one for disabling stateful autoconfiguration.
On working through these options, it became clear that there were
several ways of defining the semantics, and that the spec need not
mandate any one way. Thus, the conclusion was to not specify specific
variables, but just for the spec to say that it should be locally
possible to disable all autoconfiguration functions, and that the
functions must be enabled by default.
-----------
Node vs. Router
What part of the functions in the document should apply to routers?
The conclusion was that routers are outside the scope of the document,
with the exception of formation of the link-local address and
duplicate address detection, which apply to all IPv6 nodes.
Discussion about whether the addr conf doc should describe how
addresses are created, or whether it should be in the IPoverFoo documents.
The latter might require IPv6 code to know about different mechanisms to
create address for each IPoverFoo type. After discussion, group
agreed that IPoverFoo specs need to specify the rules for handling the
bits in the address token and the AddrConf spec should describe putting the
prefix and token together.
Steve Deering suggested: Define interface tokens as bit strings.
AddrConf spec defines how to append bit strings with prefix to
form an address. IPoverFoo specs specify how to create a bit string
and may give an example of what a link local address looks like for
this media (to avoid confusion about bit orderings).
Prefix + address token must equal 128 bits. Router is required to advertise
prefixes which when combined with the token for that particular interface type
add up to 128 bits. Zero padding not allowed, since padding rules may be
link-specific.
---------
Terminology for MAC/Hardware address
Should be "Link-Layer Address"
-----------
Terminology
Current spec uses the following terminology:
Preferred Address
Deprecated Address
Preferred Lifetime
Time-till-deprecation
Valid Lifetime
Time-till-invalidation
Group agreed these terms were OK.
--------
Discussion about whether document applies to point-to-point links,
tunnels and NBMA networks. Specification will be updated to clarify
that this specs requires the use of multicast on networks. This does
not mean to say, however, that parts of the spec, e.g. formation of
link-local address, may not apply to non-multicast capable networks.
--------
Separate ICMP Messages for Addrconf and ND
Jim Bound requested that different ICMP messages be used for addr conf
and ND. He wants different machines to be able to send each type of
message. Doesn't like the "extra" complexity of receiving combined
information. However, it was not clear how the information should be
divided up, e.g. separation of prefix advertisements from other
information advertised by routers, or separation of address-related
information (and possibly other configuration parameters) from router
advertisements, etc.
Group conclusion was to not divide this information into separate ICMP
messages.
------
[Non- addrconf related item]
The ICMP redirect will be given a code out of the informational
instead of the error cases. Code will be 137.
------
Group agreed that with the changes/clarifications made in this
meeting, addr conf (once revised) can go forward to Proposed Standard.
----------------------------------------------------------------------
Neighbor Discovery
----------------------------------------------------------------------
Erik Nordmark (presenting) & Thomas Narten
Outstanding Issues:
o Messages from off link sources
o Extra NUD probes for unsolicited information
o IPv6 Priority field in ND packets
o Randomizing Reachable Time
o RS with unspecified source
o Retransmission Timer = 10 sec.
o Preferences for Default Routers
o Prefix Redirects (instead of just host redirect)
o Reachable Confirmation / Negative vs. positive & Implementation Issues
o Implementation Language
o MTU Advertisements (per receiver MTU's)
-----
Messages from off link sources
Don't want to have to deal with messages which might have leaked in
from outside of the local link. Issue is malicious attach from off
link. Long discussion. Suggestion to always do NUD using link-local
address. All advertisements would include both global and link-local
address.
Suggested alternatives (to solve the off net problem) are hoplimit=0
and/or "don't forward" IPv6 option. "router process" with proper
semantics would help other (somewhat related) problems. This plus a
flag could tell routers to drop these packets. [See later discussion
about hoplimits]
Much more additional discussion.
Possible solutions to multiple NUD probes are:
1) carry link-local in all packets
2) zero element source route.
Discussion about not using link-local address as source of this packet
because it also causes an 8 packet NUD exchange.
General consensus that we should use a "do not forward" hop-by-hop
option and use global source address instead of link-local address.
Recipient checks if "do-not-forward" option present. This seems to
deal with off net attacks (either router drops or destination drops)
and stops 8 packet NUD exchange (back to four packets with special
rules or other mechanisms).
Possible choices are:
o Carry Link local in all ND messages
o Do nothing to special to defend against off net attacks
o Don't forward option
o Keep current spec operation of saying to not do NUD for ND packets.
Queried everyone in room to gauge consensus. Result was:
Four said they liked "don't forward" option
Eight said they liked keep current spec
One for "Alert" option to require router to do full processing
More discussion. Will revisit on second day of meeting after Erik
Nordmark and Thomas Narten present summary of changes required to ND
for making "don't forward" change.
------------
IPv6 Priority in ND Packets
Suggestion is to make ND packets high priority (over video and audio).
Proposal is to set it to 15 (highest value).
---------------
Randomizing Reachable Time
Time to send next probe. Each time need to send
Range 0.5 - 1.5 (x 30 seconds)
Use this unless get new value from router advertisements. Concern is
for nets without routers, will always use same value. Could recompute
when going into PROBE state.
Issue is how often should we recompute the random number. Current
specification says recompute when new RA is received. However, if no
RAs are present, computing the value once at boot time and then never
again results in some machines having a short (15 second)
ReachableTime, while other machines use long (45 second) time.
Recomputing each time the timer is set (e.g., whenever going into a
REACHABLE state) seems excessive.
Proposal to change computed random value once a day or if hear new
router advertisement. Group thought this was a good idea and adopted
it.
Randomize: New value in Router Advertisement occasionally receive RA /
once an hour
----------------
RS with unspecified source
Needed to make initial ND startup parallel with AddrConf. Relates to
Nordmark/Narten homework assignment. [See additional discussion]
-------
Extra NUD Probes for Unsolicited Information
Propose to introduce STALE state. First packet in STALE => PROBE.
PROBE delays for N seconds until sending NS.
Group decided to adopt this proposal.
---------
Retransmission Timer = 10 sec.
This is the timer used for retransmitting neighbor solicitations when
node doesn't have a address or for reachability when no routers are present.
Suggestion that the default for each link type should be specified in the
IPoverFoo specs.
Group decided to Change default timer value to one (1) second.
IPoverFoo spec can define link type specific default. Value in router
advertisement will override.
We can now use this timer for duplicate address detection.
------
Prefix Redirect
Proposal for Prefix Redirects. This would allow less redirects for
traffic to same destination (and destinations in same prefix).
Problem what to do when NUD detects neighbor router is down. Does it
invalidate all routes in that prefix?
No clear answer to do this. Group will continue discussion on second
day of meeting.
It was also noted that prefix redirects could be added in a backwards
compatible manner (using part of the reserved field in the redirect
message to specify the prefix length) should the need be stronger in
the future.
--------------------------------------------------------------------
Thursday, October 12, 1995
--------------------------------------------------------------------
(continuation of Prefix Redirects discussion)
Prefix redirect would result in the addition to the redirect message a
length of the prefix which the redirect covers (current redirect is
host style redirect). The prefix redirect could be disabled by
setting the prefix length to 128. Hosts could either do full longest
match routing or still deal with this on a per connection basis (e.g.,
host route). Discussion if people thought that routers would really
implement this.
Discussion about how host and routers would deal with receiving
variable length prefix redirects. Continued discussion about merits,
usage, etc. Not clear if benefits out weigh the complexity of
specifying how a host needs to deal with longest match routing.
After polling the group there was a consensus to not adding Prefix
Redirects to ND.
----------
MTU Advertisements
Proposal for hosts to be able to advertise individual MTU values.
Would allow a host to have a specific MTU for it.
After discussion which pointed out the per-host MTU (or MRU) do not
work with multicast the group decided not to do per-host MTU
advertisements.
-------------
Benefits of "Don't Forward" Option
(homework from previous day)
o Remove ICMP Sender address field from NS. Results in simplified
processing.
o Remove "no NUD for ND Packets"
o NS and NA use global source and destination addresses.
o Allow link-layer address option on all packets (except unspecified
source)
o Remove validation checks on source and destination
o Remove "no source router header" validation check
Note: Host<-->Router control messages (RA, redirects, etc.) will still
use link local addresses. This still permits hosts to maintain their
router associations in the event of renumbering.
document authors recommend that this change be made.
Bob Gilligan made proposal that instead of Hoplimit=0 or "don't
forward option", could use HopLimit=255 (max value). Host would only
accept packet if HopLimit=255 when received (e.g., it had not been
forwarded). No special processing required in routers.
This would be used for all ND messages. No "don't forward option" and no
HopLimit=0.
Group agreed to adopt these changes.
------------
Discussion about how negative advice from TCP could be use to trigger
ND. This would only be useful for on link destinations.
Additional discussion about how to use positive information from TCP.
When receiving an ACK which advances TCP window, this can be used to
provide positive notification that there is positive confirmation of
reachability. This can be used to update ND's state and keep NUD
messages from being sent.
No change to the ND specification, but this is good advice to
Implementors.
---------
Implementations language discussion will be taken off line with
document authors.
--------
Preferences
There are currently no preferences in IPv6 router advertisements.
There are preferences in IPv4. There has been a request on the
mailing list that IPv6 also have preferences.
Desire for a subset of routers on a link to be given "default" status
and others to not become default routers.
Discussion of pseudorouters (e.g., routers with less than full
functionality) and that these type of routers might work better if
there were router preferences. Not clear if the IPng specifications
should have to specify what minimum functionality that a node needs to
implement. There are too many different cases of nodes which do not
do the full functionality to try to define what all of the
interactions and combinations are.
Do the IPv4 semantics satisfy the request or do they need to be more
sophisticated?
---
Thomas Narten presentation on this topic.
Current ND draft assume routers are "smart" and send redirects
o In IPv4 reality doesn't match this ideal fix in IPV6?
o Routers send redirects based on their own view of the topology
rather than originating hosts view.
+--+ +---+ +---+
| |---R2--| | | |
H2--| | | |--R1--| |----H1
| |---R2--| | | |
+--+ +---+ +---+
R3 is "good" router
R2 is "bad" router
Ideally
o R2 forwarding table needs to keep more information; routing
operation must be keyed on (arriving interface, destination)
rather than just destination.
o Router must build separate routing tables for each arriving
interface / more computation
Does R2 have sufficient knowledge to put itself in "H2's shoes"?
o Manually entered routers require additional arguments / flags.
o If RIP is in use:
- if neighbor router adjust metrics so R2 + R3 are equivalent
from H2's perspective.
- if R2 adds 1 to each interface metric, R3 becomes better
from H2's perspective.
-----
Router advertisements w/ preferences does not eliminate requirement
for "interface-specific redirect sending"
R1-----XXXXXXXX-----H1
/ |
/ |
H2 -- XXXXXX R3
\ |
\ |
R2----XXXXXXXXX------H3
o R1 + R2 have equivalent preferences
o H2 using R2 as current default
o H2 sends data to H1
o From R2's perspective H1 is one hop away via either R1 or R3 so it
chooses R3
o From H2's perspective, R1 is clearly better
o R2 should send different redirect to H2 + H2 (e.g., arriving
interface specific)
--------
What is the big deal about preferences
o Inherent conflict between preferences for "default router" vs.
router to individual destination.
o Which router is best for destination x or default changes
dynamically
o Routers have this information first, issue is how to best to
communicate that information to hosts
o Possibilities:
+ Host wait for routers to tell them everything
- Redirect architecture achieves this
- Least complex host implementation,
- NUD handles black holes
+ Hosts using defaults routes can easily switch to new default.
- Implementation can only use a single router & and does not
load balance among equal preference routers
o Still need mechanism to probe highest preference router, if
it fails.
Note: Latter case requires redirects to be timed out. This
results in more redirects when nothing is changing.
----
Steve Deering showed a slide showing that preferences do not always
result in fewer packets. Sometimes preference result in more
redirect packets, sometimes not.
H2 H3
| |
#####N2#### ###N3#######
| \ / |
| \ / |
| \ / |
| R1 |
R2 | R3
| | |
| | |
########N1########################
|
H1
For traffic from H1 to H3 where R1 is best router for destinations on
N2 and N3
With no router preferences:
If R1 goes down, 50% of the time H1 will pick R3 as default
resulting in no redirect when it initiates a connection to H3.
The other 50% of the time a redirect will result.
With router preferences of R1 being the highest, R2 next highest,
and R3 the lowest:
If R1 goes down, H1 will always pick R2 as default. This will
result in a redirect being sent every time H1 initiates a
connection to H3.
It is not possible to set up the router preferences in manner which
results in less redirect traffic.
----
Narten:
Routers learned via redirects become stale
o Easiest is simply timeout redirects every N seconds
o # of redirects increase
o Does not eliminate the need for routers to do route calculations
based on source.
o Preference potentially reduces the need for above but does not
eliminate the need completely.
Long discussion about merits and issues regarding adding router
preferences.
------
Chair polled room on desire for router preferences:
Y= want them, N= do not think should be added
N N N N N N N N N N N (there were four non-votes)
Deering proposes we do not add preferences, do working group last
call, if intensity of debate high is enough from the last call, we
will not forward to IESG and continue discussion at the Dallas IETF
meeting in December.
The group accepted Deering's proposal.
----
Discussion about the need for preferences in anycast address NA's.
Anycast addresses were intended to denote "a router" rather than "the
best router". In particular, the routing subsystem delivers a packet
to "to a router" rather than "the best router". Thus associating
preferences with anycast addresses was not really appropriate.
After discussing the issues, group decided to not add any preferences
for anycast addresses in NA.
------
Erik Nordmark presented analysis on Boot Timing with current ND
default timer values.
Host:
DAD:
Random [0-1] second delay
Send 1 NS, wait for 1 second
RS:
Random [0-1] second delay
Send up to 3 RS separated by 3 seconds
Router:
Receive RS
Start random timer [0-6] seconds
Timer: if received more than one RS while waiting
Send RA multicast, else unicast RA.
It should be possible to send DAD and RS at the same time, to
eliminate the second random [0-1] delay.
After much discussion group decided to change so Router will respond
with multicast RA (wait random [0-.5 second) and not send another RA
for 3 seconds (independent of number of RS received in interval).
Routers will always multicast the RA in response to an RS. This
should result in faster response to RS and fewer RA on link. Router
procedure becomes:
Receive RS
If have not sent RA within 3 seconds
Start Random timer [0-.5] seconds
Send RA multicast
else
wait until (3 seconds + Random [0 - .5)) timer expires
Send RA multicast
endif
----------
Document Organization
Desire to restructure document to move packet formats to beginning of
document (after overview), use standard internet bit order, make
implementation details generic if appropriate, and other similar
formatting changes.
Add statement that the protocol is the packet formats and external
behavior on the wire and the implementation guidelines are a
conceptual model. The protocol is what is being standardized.
Implementations are not required to implement guidelines exactly as
described.
------
Group agreed that once these changes are made we can do a working
group last call. Authors will have a new draft within 3 weeks.
----------------------------------------------------------------------
Minimum Reassemble Size
----------------------------------------------------------------------
RFC of IPv6 will say that minimum reassembly size is 1500 bytes.
----------------------------------------------------------------------
"IGMP" for Link-Local Multicast Groups
----------------------------------------------------------------------
Do membership reports need to be done for link-local multicast groups?
It is not clear if required link-local multicast addresses need to be
added to IGMP group requests. Could only use for groups which are
created by the hosts and not for the required multicast group
addresses. Having them in the group would make it easier to prune
traffic to groups which do not have any members.
Group decided to not include pre-defined link-local multicast
addresses in IGMP group messages but will send IGMP reports for other
link-local multicast addresses.
----------------------------------------------------------------------
Thanks to Scott Behnke / Dyncorp and Allison Mankin / ISI for hosting
the meeting.
Meeting adjoined!
----------------------------------------------------------------------