4) Section 5.2.4 needs to say something about what the host should do regarding its autoconfigured addresses. The link local address(es) need to be considered "Optimistic" until confirmed by either an RA with "yes", as we discussed on the list. What about the unicast global address(es)? Should we say that the node should stop sending traffic with those as a source address until the RA with "yes" comes back? What happens if the node receives traffic at that source address while it is waiting for the RA?
I've been meaning to write this up for some time. Below is some text for a
section to add to draft-pentland about the interaction of DNA with host
address configuration, both unicast and multicast. It covers stateful and
stateless address configuration. The text is intended to be for a new
section in draft-pentland, presuming, of course, that the WG approves
draft-pentland as the basis for the WG draft.
Comments?
jak
---------------------------
5.2.5 DNA and Address Configuration
When a host moves to a new link, a potential exists for a change in the
validity of its unicast link local and global addresses, and its multicast
addresses. In this section, host processing for address configuration is
specified. The section considers both statelessly and statefully configured
addresses.
5.2.5.1 Duplicate Address Detection
A DNA host MUST support optimistic Duplicate Address Detection [RFCoDAD] for
autoconfiguring unicast link local addresses. If a DNA host uses address
autoconfiguration [RFC2462] for global addresses, the DNA host MUST support
optimistic Duplicate Address Detection for autoconfiguring global unicast
addresses.
5.2.5.2 DNA and the Address Autoconfiguration State Machine
When a link level event occurs indicating that the host has moved from one
link to another, DNA requires the host to determine whether a change in IP
link has occured by sending an RS. The DNA host SHOULD select one of its
link local addresses that is in the "Confirmed" state (i.e. assigned to an
interface) and utilize that as the source address on the DNA RS. If the host
has no "Confirmed" link local addresses but does have an address in the
"Optimistic" state, it MUST utilize that as the source address. Since
optimistic Duplicate Address Detection is required for DNA, the host should
not have any addresses in the "Tentative" state. If the host currently has
no link local addresses, it MUST construct one and put it into the
"Optimistic" state. Note that the presence of a duplicate link local address
on the link will not interfere with the ability of the link to route a
unicast RA from the router back to the host, because the TSLLA option is
included in the RS and is utilized by the router on the RA frame.
If the host receives no RA in reply, it MUST transition all addresses to the
"Optimistic" state and act according to [RFC2461] as if no router has been
discovered on the link.
If the received RAs indicate that the host has not moved to a new IP link
(i.e. the IP link has not changed) either because a DNA RA has been received
or nonDNA RAs have been received and the host performs CPL, then the host is
REQUIRED to leave the state of all "Confirmed" and "Optimistic" addresses
unchanged and continue with optimistic Duplicate Address Detection for
"Optimistic" addresses. This includes both unicast link local and
statelessly autoconfigured unicast global addresses (but not statefully
configured global unicast addresses).
If the received RAs indicate that the host has moved to a new IP link (i.e.
the IP link has changed), either because a DNA RA has been received or
nonDNA RAs have been received and the host performs CPL, the host MUST
transition all autoconfigured addresses in the "Confirmed" state to
"Optimistic" and begin optimistic Duplicate Address Detection signaling for
them. Optimistic Duplicate Address Detection signaling for "Optimistic"
addresses MUST also be restarted and continued until either a duplicate is
detected or the signaling timeout occurs, according to [RFCoDAD].
5.2.5.3 DNA and Statefully Configured Addresses
The DHCPv6 specification [RFC3315] requires hosts to send a DHCPv6 CONFIRM
message when a change in link is detected. Since the DNA protocol provides
the same level of movement detection as the DHCPv6 CONFIRM, it is
RECOMMENDED that DNA hosts not utilize the DHCPv6 CONFIRM message when a DNA
RA is received, to avoid excessive signaling.
When a DNA RA is received, statefully configured addresses are handled
similarly to autoconfigured addresses. If the received RA indicates that the
host has not moved to a new IP link, the statefully configured addresses are
still valid and can continue to be used until their lease expires. If the
DNA RA indicates that the host has moved to another link, the host is
REQUIRED to begin stateful configuration again.
If, however, a nonDNA RA is received, the host SHOULD use the DHCPv6 CONFIRM
message as described in RFC 3315 rather than wait for additional RAs to
perform CPL, since it reduces the amount of time required for the host to
confirm whether or not it has moved to a new link. If the CONFIRM message
validates the addresses, then the host can continue to use them. If not, the
host MUST perform DHCPv6 stateful address configuration again, as described
by RFC 3315.
5.2.5.4 Change in IP Link Address Configuration Type
It is possible that a host may encounter a change in IP link address
configuration type (for example, from stateful to stateless) when it moves
from one IP link to another. The solicited RA will indicate what type of
address configuration to perform in this case, and MUST be followed.
In general, a change in IP link address configuration type should not occur
if the host does not change IP link. However, if the initial DNA RA
indicates that the host has not changed IP link but the IP link address
configuration type is different from the last indication of the address
configuration type on the link, the host SHOULD wait for additional RAs
before beginning address reconfiguration. If all RAs agree as to the address
configuration type change, then the host MUST perform address
reconfiguration as specified by the RAs even though it has not changed to a
new link. If the RAs do not agree, then it is likely that the routers are
misconfigured, and the host MAY continue to use previous addresses as
described above, but an error message should be logged to inform the network
administrator, and the host should be vigilant for possible errors.
5.2.5.5 Multicast Address Configuration
If the returned DNA RA indicates that the host has not moved to a new IP
link, no further action is required for multicast addresses to which the
host has subscribed.
If, on the other hand, the DNA RA indicates that the host has moved to a new
IP link, the host MUST issue MLD [RFC3810] messages to the router for
subscribed multicast addresses, including the
Solicited_Node_Multicast_Address for any unicast addresses configured.
James Kempf wrote: > > When a link level event occurs indicating that the host has moved from one > link to another, DNA requires the host to determine whether a change in IP > link has occured by sending an RS. The DNA host SHOULD select one of its > link local addresses that is in the "Confirmed" state (i.e. assigned to an > interface) and utilize that as the source address on the DNA RS. Doesn't this imply that if the host has moved to a new link, and the Confirmed address is a duplicate on that link, that the host might accidentally overwrite the neighbor cache entry for the existing user of that link-local address? That would seem to defeat the purpose of DAD. It is safer to, immediately when the link level event arrives, switch all Confirmed addresses to Optimistic. Then if it turns out that the host didn't move, it can switch those back to Confirmed. And if it turns out that the host did move, it can send the actual NS DAD probe for all the IP addresses it has (the existing link-local addresses, as well as any newly configured IP addresses). > If the returned DNA RA indicates that the host has not moved to a new IP > link, no further action is required for multicast addresses to which the > host has subscribed. > > If, on the other hand, the DNA RA indicates that the host has moved to a new > IP link, the host MUST issue MLD [RFC3810] messages to the router for > subscribed multicast addresses, including the > Solicited_Node_Multicast_Address for any unicast addresses configured. It actually needs to handle the Solicited node multicast addresses before starting any DAD procedure, to ensure that it will receive DAD messages when there are MLD snooping L2 switches. Erik
Jak, >>5.2.5.3 DNA and Statefully Configured Addresses >>When a DNA RA is received, statefully configured addresses are handled >>similarly to autoconfigured addresses. Just curious to know, It means that DNA RA has a kind of M/O flags of a general RA (rfc2462) or just uses them ? Above mention does not clear for me at this point. >>If the DNA RA indicates that the host has moved to another link, the host is >>REQUIRED to begin stateful configuration again. Suggested to be added following above sentence (if appropriate of course), In DNA, it is beneficial to rapidly configure hosts. The DHCPv6 operation as 4-message exchange, however, allows for redundancy (multiple DHCPv6 servers) without wasting addresses, as addresses are only provisionally assigned to a host until the host chooses and requests one of the provisionally assigned addresses. If the DNA host supports the Rapid Commit Option [RFC3315], it is possible that the exchange can be shortened from a 4-message exchange to a 2-message exchange. Regards, --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics.
>Doesn't this imply that if the host has moved to a new link, and the
>> Confirmed address is a duplicate on that link, that the host might
>> accidentally overwrite the neighbor cache entry for the existing user of
>> that link-local address?
>>
>> That would seem to defeat the purpose of DAD.
>>
Draft-pentland in Section 5.2.3 says this:
Hosts MUST include a tentative source link layer address option
(TSLLAO) in the RS message [13]. The router solicitation message is
sent to the All_Routers_Multicast address and the source address MUST
be the link local address of the host.
The router uses the TSLLAO to route back to the host, and the definition of
the TSLLAO means that it won't pollute the neighbor cache if there's a
duplicate. So there should be no effect on the router neighbor cache even if
there is a duplicate, and the router shouldn't send the RS to any other node
even if there is a duplicate because the TSLLAO will allow link routing to
work correctly.
>> It is safer to, immediately when the link level event arrives, switch
>> all Confirmed addresses to Optimistic.
>> Then if it turns out that the host didn't move, it can switch those back
>> to Confirmed.
>> And if it turns out that the host did move, it can send the actual NS
>> DAD probe for all the IP addresses it has (the existing link-local
>> addresses, as well as any newly configured IP addresses).
>>
I considered that, but the problem is that if the addresses are switched to
"Optimistic" . Section 3.3 of draft-ietf-ipv6-optimistic-dad says this about
the "Optimistic" state:
* (modifies 5.4) As soon as the initial Neighbor Solicitation is
sent, the Optimistic Address is configured on the interface and
available for use immediately. The address MUST be flagged as
'Optimistic'.
so what this means to me is that the node would have to send NSes on the
link prior to switching its addresses to Optimistic, even if it is on the
same link, because it doesn't find out that it is on the same link until
after the RA returns. I'm not sure whether the extra traffic overhead on
each move is really necessary or beneficial.
Unfortunately, there's no good solution here. Here are the possible states
and their problems:
- Optimistic: requires NS/DAD signaling even if the host hasn't switched IP
links. If the host has switched IP links, then any packets sent with a
global unicast address while the RS/RA transaction is underway will be sent
with an address that is topologically incorrect (because the host may send
packets while an address is in "Optimistic").
- Confirmed: If the host has switched links, then any packets sent with a
global unicast address will be sent with an address that is topologically
incorrect, as above.
- Tentative: requires NS/DAD signaling even if the host hasn't switched IP
links, but no topologically incorrect addresses will be used if the host has
switched links since a host can't send any packets from a Tentative address.
- Deprecated: not relevant, since the host can continue to use the address
for existing connections and therefore would have the same problem with
topological incorrectness here as with Optimistic and Confirmed.
If we are OK with having the host signal to reconfirm addresses on every
move, then we could switch the link local address used as the source address
on the RS to Optimistic, and the others to Tentative prior to sending the
RS. This would avoid the problem with topological incorrectness for global
unicast addresses. When the RS returns, we could switch everything to
Optimistic if the host is on the same IP link, since no change in topology
has occured. If the IP link has changed, then the link local addresses could
be switched to Optimistic and the unicast global addresses could be dropped
(actually "dropped" is not in the state machine, and Deprecated isn't
appropriate because RFC 2462 allows the host to continue using Deprecated
addresses), and the host would then configure new global unicast addresses.
Any other ideas about how to handle this?
>>
>>
>
>>> > If the returned DNA RA indicates that the host has not moved to a new IP
>>> > link, no further action is required for multicast addresses to which the
>>> > host has subscribed.
>>> >
>>> > If, on the other hand, the DNA RA indicates that the host has moved to a
new
>>> > IP link, the host MUST issue MLD [RFC3810] messages to the router for
>>> > subscribed multicast addresses, including the
>>> > Solicited_Node_Multicast_Address for any unicast addresses configured.
>
>>
>> It actually needs to handle the Solicited node multicast addresses
>> before starting any DAD procedure, to ensure that it will receive DAD
>> messages when there are MLD snooping L2 switches.
>>
Yes, that's true. I'll switch that around to make it clear.
jak
>>5.2.5.3 DNA and Statefully Configured Addresses
>
>>
>
>>> >When a DNA RA is received, statefully configured addresses are handled
>>> >similarly to autoconfigured addresses.
>
>>
>> Just curious to know,
>> It means that DNA RA has a kind of M/O flags of a general RA (rfc2462)
>> or just uses them ? Above mention does not clear for me at this point.
>>
The existing flags are unchanged.
>>> >If the DNA RA indicates that the host has moved to another link, the host
>
>> is
>
>>> >REQUIRED to begin stateful configuration again.
>
>>
>> Suggested to be added following above sentence (if appropriate of course),
>>
>> In DNA, it is beneficial to rapidly configure hosts. The DHCPv6 operation
as
>> 4-message exchange, however, allows for redundancy (multiple DHCPv6
>> servers) without wasting addresses, as addresses are only provisionally
>> assigned to a host until the host chooses and requests one of the
>> provisionally
>> assigned addresses. If the DNA host supports the Rapid Commit Option
>> [RFC3315], it is possible that the exchange can be shortened from a
>> 4-message exchange to a 2-message exchange.
>>
Sure, thanx for pointing this out.
jak
Hi Jim, Thanks for doing this. It looks like it will be a good addition to the draft once the few issues that have been raised are addressed. I have a couple of comments too: > 5.2.5.2 DNA and the Address Autoconfiguration State Machine > > When a link level event occurs indicating that the host has moved from one > link to another, DNA requires the host to determine whether a change in IP > link has occured by sending an RS. The DNA host SHOULD select one of its We need to keep the terminology consistent (and this goes for the rest of the draft too...) The last discussions on this list that I can find (around 26/5/05) talked about "point of attachment" for what you have here called "link", and "link" for what you have called "IP link". I think the intention is to have them defined in the "L2 event notifications for DNA" document. > If the received RAs indicate that the host has moved to a new IP link (i.e. > the IP link has changed), either because a DNA RA has been received or > nonDNA RAs have been received and the host performs CPL, the host MUST > transition all autoconfigured addresses in the "Confirmed" state to > "Optimistic" and begin optimistic Duplicate Address Detection signaling for > them. Optimistic Duplicate Address Detection signaling for "Optimistic" > addresses MUST also be restarted and continued until either a duplicate is > detected or the signaling timeout occurs, according to [RFCoDAD]. This sounds right for link-local addresses, but I think global addresses will be invalid because of the link change and should be dropped altogether. New global addresses may be formed based on the prefix information in the RA and those should go into the Optimistic state. Brett.
| Topic DNASoln1Issue015 . { Edit | Attach | Ref-By | Printable | Diffs | r1.2 | > | r1.1 | More } |
|
Revision r1.2 - 14 Jun 2005 - 05:22 GMT - Main.BrettPentland Parents: WebHome > DNASolution1 |
Copyright © 1999-2003 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback. |