Hello,
To make this discussion quicker, I thought it would be better to have my
suggested changes around as I saw them in the 6lowpan-ND. To that end, may I
present "6lowpan-nd-co" document available at
http://www.newae.com/tiki-download_wiki_attachment.php?attId=64
I've attached the diff here, which is also at
http://www.newae.com/tiki-download_wiki_attachment.php?attId=65
This basically changes 6lowpan-ND so a host always sends the NS from a
link-local address based on the EUI-64.
By doing this, you eliminate everything "tricky" I think. Note you CAN send
from any link-layer address, you don't need to have an EUI-64 based
link-layer address. You are simply saying that the IPv6 address is EUI-64
based, which I think is a simple and fair assumption since this is a
known-unique IPv6 address. Indeed it currently has this in it anyway
indicating the presence of a link-local based on the EUI64:
A link-local address is formed based on
the EUI-64 assigned to the interface, and then the host sends Router
Solicitation messages as described in [RFC4861] Section 6.3.7.
It needs some clean-up for corner cases, but the basic idea is there. The
flow is as follows for multi-hop:
1) 6LN configures it's EUI-64 address, does RS/RA from this address
(which I'll call LL64).
2) 6LN sends NS from the LL64. The ARO has the registered address as
its desired global, and additionally the ARO now has a field that includes
the L2 address corresponding with the desired global. The SLLAO has the
link-layer address of the LL64, for 802.15.4 this would be the same as the
EUI64 (but is not required to be for this to work)
3) The 6LR checks for duplicates and/or sends along to 6LBR, as was
done before (except the ARO is a little longer)
4) 6LBR sends a NA response to 6LR. It just copies the ARO from the
received NS, but changes the status field.
5) 6LR receives the NA.
a. If status == 0, it can now put a NC entry based on the IPv6 & L2
address in the ARO.
b. Sends a response to the 6LN. This is done by extracting the EUI64
from the ARO, and forming a link-local address per RFC4944. It then sends
the NA to this IPv6 address, with the ARO copied exactly as received from
the 6LBR. The node uses normal IPv6 methods to get the link-layer address of
this IPv6 address (aka: NC entry that could have been created in step 1 or
2).
6) 6LN receives NA with status, can start using that L2 & IPv6 address.
Note that although the L2 address is carried in the ARO now, it isn't
actually used for anything except to avoid requiring the temporary NCE. This
greatly simplifies flow of messages, since you almost never need to reform
them as the same ARO is used everywhere.
I think such a flow also has the advantage for those using "regular" IPv6
stacks that it requires minimal hacks. In step 5b for example you use the
regular neighbor cache to pass the response back, which would have been
populated in step 1 or 2 in a normal stack.
For those using custom IPv6 stacks it makes implementation & optimization
very easy, since you pass basically fixed messages around. In step 5b for
example you could send to the EUI-64 directly, avoiding the need for any NC
stuff if you want.
Regards,
-Colin O'Flynn
--- E:/Documents/ipso/ietf/draft-ietf-6lowpan-nd-12.txt Thu Aug 26 12:33:59 2010
+++ E:/Documents/ipso/ietf/draft-ietf-6lowpan-nd-co.txt Thu Aug 26 12:29:56 2010
@@ -7,15 +7,15 @@
Intended status: Standards Track IP Infusion
Expires: February 4, 2011 E. Nordmark
Oracle, Inc.
August 3, 2010
Neighbor Discovery Optimization for Low-power and Lossy Networks
- draft-ietf-6lowpan-nd-12
+ draft-ietf-6lowpan-nd-CO
Abstract
The IETF 6LoWPAN working group defines IPv6 for low-power and lossy
networks (LLNs) such as IEEE 802.15.4. This and other similar link
technologies have limited or no usage of multicast signaling due to
energy conservation. In addition, the wireless network may not
@@ -713,16 +713,15 @@
hop-limit=255 check.
3.5. Neighbor Cache Management
The use of explicit registrations with lifetimes plus the desire to
not multicast Neighbor Solicitation messages for hosts imply that we
manage the Neighbor Cache entries slightly differently than in
- [RFC4861]. This results in three different types of NCEs and the
- types specify how those entries can be removed:
+ [RFC4861].
Shelby, et al. Expires February 4, 2011 [Page 13]
@@ -733,35 +732,19 @@
[RFC4861] that allow for garbage collection
when low on memory.
Registered: Entries that have an explicit registered
lifetime and are kept until this lifetime
expires or they are explicitly unregistered.
- Tentative: Entries that are temporary with a short
- lifetime, which typically get converted to
- Registered entries.
-
- Note that the type of the NCE is orthogonal to the states specified
- in [RFC4861].
-
- When a host interacts with a router by sending Router Solicitations
- this results in a Tentative NCE. Once a node successfully registers
- with a Router the result is a Registered NCE. As Routers send RAs to
- hosts, and when routers optionally receive RA messages or receive
- multicast NS messages from other Routers the result is Garbage-
- collectible NCEs.
Neighbor Cache entries on Routers can additionally be added or
deleted by a routing protocol used in the 6LoWPAN. This is useful if
the routing protocol carries the link-layer addresses of the
- neighboring routers. Depending on the details of such routing
- protocols such NCEs could be either Registered or Garbage-
- collectible.
-
+ neighboring routers.
4. New Neighbor Discovery Options
This section defines new Neighbor Discovery message options used by
this specification. The Address Registration Option is mandatory,
whereas the Authoritative Border Router Option and 6LoWPAN Context
Option are optional.
@@ -786,76 +769,73 @@
same option is included in corresponding Neighbor Advertisement (NA)
messages with a Status field indicating the success or failure of the
registration. This option is always host initiated.
The ARO is reused for the optional multihop Duplicate Address
- Detection from 6LRs to 6LBRs, in which case it has a different
+ Detection from 6LRs to 6LBRs, in which case it may have a different
Length. In that case one or more AROs can be included in an NS.
The ARO is required for reliability and power saving. The lifetime
field provides flexibility to the host to register an address which
should be usable (continue to be advertised by the 6LR in the routing
protocol etc.) during its intended sleep schedule.
The sender of the NS also includes the EUI-64 of the interface it is
registering an address from. This is used as a unique ID for the
detection of duplicate addresses. It is used to tell the difference
between the same node re-registering its address and a different node
(with a different EUI-64) registering an address that is already in
- use by someone else.
-
- When the ARO is used by hosts an SLLA option MUST be included and the
- address that is registered MUST be the IPv6 source address for the
- Neighbor Solicitation message. Thus the Registered Address field is
- omitted and the Length field MUST be two. When the ARO is used for
- the optional multihop DAD between a 6LR and a 6LBR then there is no
- SLLA option, the Registered Address field is included and the Length
- field MUST be four.
-
+ use by someone else.
+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Status | Reserved |
+ | Type | Length | Status | LLALength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EUI-64 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
- + Registered Address (Optional) +
+ + Registered Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
+ | |
+ + Tenative Link-Layer Address +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shelby, et al. Expires February 4, 2011 [Page 15]
Internet-Draft ND Optimization for LLNs August 2010
Fields:
Type: TBD1
Length: 8-bit unsigned integer. The length of the option in
- units of 8 octets. 2 without or 4 with the Registered
- Address.
+ units of 8 octets. 4 without any link-layer address.
Status: 8-bit unsigned integer. Indicates the status of a
registration in the NA response. MUST be set to 0 in
NS messages. See below.
+
+ LLALength: 8-bit unsigned integer. Number of bytes of the
+ link-layer address that is valid.
Reserved: This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Registration Lifetime: 16-bit unsigned integer. The amount of time
in a unit of 10 seconds that the router should retain
the Neighbor Cache entry for the sender of the NS that
@@ -866,14 +846,22 @@
Registered Address: 128-bit optional field. MUST NOT be sent by a
host. Used for the optional router-router
registrations on behalf of a host. Carries the host
address, which was contained in the IPv6 Source field
in the original NS that contained the option sent by
the host.
+
+ Tenative Link-Layer Address: Variable length but must be multiple of 8
bytes.
+ Only the first LLALength bytes are valid, any
remaining
+ bytes MUST be initilized to zero by the
sender and
+ MUST be ignored by the receiver. If the
address
+ registration succeeds, this will be the
corresponding
+ link-layer address associated with the
registered
+ IPv6 address. Used to update the neighbour
cache.
The Status values used in Neighbor Advertisements are:
+--------+--------------------------------------------+
| Status | Description |
+--------+--------------------------------------------+
| 0 | Success |
@@ -1207,25 +1195,30 @@
The host triggers sending Neighbor Solicitation (NS) messages
containing an ARO when a new address is configured, when it discovers
a new default router, or well before the Registration Lifetime
expires. Such an NS MUST include a Source Link-Layer Address (SLLA)
option, since the router needs to record the link-layer address of
the host. An unspecified source address MUST NOT be used in NS
messages.
+
+ The NS used by hosts for address registration purposes MUST use
+ the link-local address which is based on the EUI-64 contained in
+ the ARO as the source. This address is formed according to section
+ 7 of [RFC4944].
+
5.5.2. Processing a Neighbor Advertisement
A host handles Neighbor Advertisement messages as specified in
[RFC4861], with added logic described in this section for handling
the Address Registration option.
In addition to the normal validation of a Neighbor Advertisement and
its options, the Address Registration option is verified as follows
- (if present). If the Length field is not two, the option is silently
- ignored. If the EUI-64 field does not match the EUI-64 of the
+ (if present). If the EUI-64 field does not match the EUI-64 of the
interface, the option is silently ignored.
If the status field is zero, then the address registration was
Shelby, et al. Expires February 4, 2011 [Page 22]
@@ -1355,15 +1348,15 @@
6. Router Behavior for 6LR and 6LBR
Both 6LRs and 6LBRs maintain the Neighbor Cache [RFC4861] based on
the Address Registration Options they receive in Neighbor
Advertisement messages from hosts, Neighbor Discovery packets from
other nodes, and potentially a routing protocol used in the 6LoWPAN
as outlined in Section 3.5. Note that the handling of ARO from other
- routers (with Length=4) is specified in Section 8.
+ routers is specified in Section 8.
The routers SHOULD NOT garbage collect Registered Neighbor Cache
entries (see Section 3.4) since they need to retain them until the
Registration Lifetime expires. Similarly, if Neighbor Unreachability
Detection on the router determines that the a host is UNREACHABLE
(based on the logic in [RFC4861]), the Neighbor Cache entry SHOULD
NOT be deleted but be retained until the Registration Lifetime
@@ -1419,23 +1412,15 @@
information or different, from different 6LBR, then it will need to
keep those prefixes and context information separately so that the
RAs the 6LR sends will maintain the association between the ABRO and
the prefixes and context information. The router can tell which 6LBR
originated the prefixes and context information from the 6LBR Address
field in the ABRO. When a router has information tied to multiple
ABROs, a single RS will result in multiple RAs each containing a
- different ABRO.
-
- A Router Solicitation might be received from a host that has not yet
- registered its address with the router. Thus the router MUST NOT
- modify an existing Neighbor Cache entry based on the SLLA option from
- the Router Solicitation. However, a router MAY create a Tentative
- Neighbor Cache entry based on the SLLA option. Such a Tentative
- Neighbor Cache entry SHOULD be timed out in TENTATIVE_NCE_LIFETIME
- seconds unless a registration converts it into a Registered NCE.
+ different ABRO.
A 6LR or 6LBR MUST include a Source Link-layer address option in the
Router Advertisements it sends. That is required so that the hosts
will know the link-layer address of the router. Unlike in [RFC4861],
the maximum value of the RA Router Lifetime field MAY be up to 0xFFFF
(18 hours).
@@ -1467,48 +1452,46 @@
A router handles Neighbor Solicitation messages as specified in
[RFC4861], with added logic described in this section for handling
the Address Registration option.
In addition to the normal validation of a Neighbor Solicitation and
its options, the Address Registration option is verified as follows
- (if present). If the Length field is not two, or if the Status field
- is not zero, then the Neighbor Solicitation is silently ignored.
- Note that Section 8.2 specify optional behavior for a 6LBR for other
- Length field values.
+ (if present). If the Status field is not zero, then the Neighbor
+ Solicitation is silently ignored. Note that Section 8.2 specifies
+ optional behavior for a 6LBR.
If the source address of the NS is the unspecified address, or if no
SLLA option is included, then any included ARO is ignored, that is,
the NS is processed as if it did not contain an ARO.
6.5.1. Checking for Duplicates
If the NS contains a valid ARO, then the router inspects its Neighbor
- Cache on the arriving interface to see if it is a duplicate. If
- there is no Neighbor Cache entry for the IPv6 source address of the
- NS, then it isn't a duplicate. If there is such a Neighbor Cache
- entry and the EUI-64 is the same, then it isn't a duplicate either.
- Otherwise it is a duplicate address. Note that if multihop DAD
- (Section 8.2) is used then the checks are slightly different to take
- into account Tentative Neighbor Cache entries.
+ Cache on the arriving interface to see if it is a duplicate. If there
+ is no Neighbor Cache entry for the IPv6 registered address in the ARO,
+ then it isn't a duplicate. If there is an entry that matches, but the
+ EUI-64 also matches, then it isn't a duplicate either.
In the case it is a duplicate address then the router responds with a
unicast Neighbor Advertisement (NA) message sent to the source link-
layer address (from the Source Link-Layer Address (SLLA) option) of
the NS. The NA is formatted with a copy of the ARO from the NS, but
with the Status field set to one to indicate it was a duplicate. In
this case there is no modification to the Neighbor Cache.
6.5.2. Updating the Neighbor Cache
If ARO did not result in a duplicate address being detected as above,
then if the Registration Lifetime is non-zero the router creates (if
it didn't exist) or updates (otherwise) a Neighbor Cache entry for
- the IPv6 source address of the NS. If the Neighbor Cache is full and
- a new entry needs to be created, then the router responds with a
+ the IPv6 registered address in the ARO. This Neighbor Cache entry
+ uses the tenative link-layer address field in the ARO as the
+ link-layer address for the Neighbor Cache entry. If the Neighbor Cache
+ is full and a new entry needs to be created, then the router responds with a
Shelby, et al. Expires February 4, 2011 [Page 27]
Internet-Draft ND Optimization for LLNs August 2010
@@ -1531,18 +1514,14 @@
Should the Registration Lifetime in a Neighbor Cache entry expire,
then the router MUST delete the cache entry.
The addition and removal of Registered Neighbor Cache entries would
result in notifying the routing protocol.
- Note: If the optional multihop DAD (Section 8.2) is used, then the
- updating of the Neighbor Cache is slightly different due to Tentative
- NCEs.
-
6.5.3. Address Resolution between Routers
There needs to be a mechanism somewhere for the routers to discover
each other's link-layer addresses. If the routing protocol used
between the routers provides this, then there is no need for the
routers to use the Address Registration option between each other.
Otherwise, the routers MAY use the ARO. When routers use ARO to
@@ -1856,63 +1835,40 @@
multihop DAD needs to be repeated against the 6LBRs to ensure that
the entry for the address in the 6LBRs does not time out, but that
can be done asynchronously with the response to the hosts. For
instance, by tracking how much is left of the lifetime the 6LR
registered with the 6LBRs and re-registering with the 6LBR when this
lifetime is about to run out.
- For the synchronous multihop DAD the 6LR performs some additional
- checks to ensure that it has a Neighbor Cache entry it can use to
- respond to the host when it receives a response from a 6LBR. This
- consists of checking for an already existing (Tentative or
- Registered) Neighbor Cache entry for the registered address with a
- different EUI-64. If such a Registered NCE exists, then the 6LR
- SHOULD respond that the address is a duplicate. If such a Tentative
- NCE exists, then the 6LR SHOULD silently ignore the ARO thereby
- relying on the host retransmitting the ARO. (This is needed to
- handle the case when multiple hosts try to register the same IPv6
- address at the same time.) If no Neighbor Cache entry exists, then
- the 6LR MUST create a Tentative Neighbor Cache entry with the EUI-64
- and the SLLAO. This entry will be used to send the response to the
- host when the 6LBR responds.
-
When a 6LR receives a Neighbor Solicitation containing an Address
Registration option with a non-zero Registration Lifetime and it has
no existing Registered Neighbor Cache entry, then with this mechanism
the 6LR will invoke synchronous multihop DAD.
The 6LR will unicast a new Neighbor Solicitation message to one or
- more 6LBRs, where the NS contains an ARO with the host's address in
- the Registered Address field. This NS will be forwarded by 6LRs
- until it reaches the 6LBR, hence its IPv6 hop limit field might be
- less than 255 when received by the 6LBR. The 6LBR will respond with
- a Neighbor Advertisement message containing an ARO, which might have
- a hop limit less than 255 when it reaches the 6LR.
+ more 6LBRs, where the NS contains a copy of the ARO from the host.
+ This NS will be forwarded by 6LRs until it reaches the 6LBR, hence
+ its IPv6 hop limit field might be less than 255 when received by
+ the 6LBR. The 6LBR will respond with a Neighbor Advertisement
+ message containing an ARO, which might have a hop limit less than
+ 255 when it reaches the 6LR.
When the 6LR receives the NA from the 6LBR containing a ARO, it will
- look for a matching (same IP address and EUI-64) (Tentative or
- Registered) Neighbor Cache entry. If no such entry is found then the
- ARO is silently ignored. If an entry is found and the ARO had
- Status=0 then the 6LR will mark the Tentative Neighbor Cache entry as
- Registered. In all cases when an entry is found then the 6LR will
- respond to the host with an NA, copying the Status field from the ARO
- it received from the 6LBR.
-
-
+ form an IPv6 address based in the EUI-64 in the ARO and the link-local
+ prefix, as specified in section 7 of [RFC4944]. It will then send a
+ NA to this IPv6 address, with a copy of the ARO received from the 6LBR.
+
+ If the ARO had a Status=0, the 6LR will additionally put a new entry
+ in it's Neighbor Cache as per section 6.5.2.
Shelby, et al. Expires February 4, 2011 [Page 34]
Internet-Draft ND Optimization for LLNs August 2010
-
- A Tentative Neighbor Cache entry SHOULD be timed out
- TENTATIVE_NCE_LIFETIME seconds after it was created in order to allow
- for another host to attempt to register the IPv6 address.
-
8.2.1. Special Message Validation
Due to the forwarding of the above special NS/NA between the 6LR and
6LBR the hop limit check on receipt MUST be bypassed for such
messages that contain a ARO with a Length field of 4. The receipt of
such messages MUST NOT modify any state on the router with the
exception of the DAD table below.
@@ -1924,56 +1880,48 @@
structure the DAD table. It is indexed by the IPv6 address - the
Registered Address in the ARO - and contains the EUI-64 of the host
that is using that address.
8.2.3. 6LR Sending a special Neighbor Solicitation
When a 6LR that implements the optional multihop DAD receives an NS
- from a host (the ARO has Length = 2) and subject to the above checks,
- the 6LR forms and sends an NS to at least one 6LBR. The NS contains
- the following information:
+ from a host and subject to the above checks, the 6LR forms and sends
+ an NS to at least one 6LBR. The NS contains the following information:
o In the IPv6 source address, a global address of the 6LR.
o In the IPv6 destination address, the address of the 6LBR.
o In the IPv6 hop limit, 255 or a smaller number.
o In the NS Target Address, the address of the 6LBR.
o In the ARO the Status field MUST be set to zero
- o In the ARO the EUI-64 and Registration lifetime are copied from
+ o In the ARO the EUI-64, Registration lifetime, Registered Address,
+ LLALen, and Tenative Link-Layer Address are copied from
the ARO received from the host.
- o In the ARO and the Registered Address set to the IPv6 address of
- the host, that is, the sender of the triggering NS.
-
When a 6LR receives an NS from a host with a zero Registration
Lifetime then, in addition to removing the Neighbor Cache entry for
the host as specified in section Section 6, an NS is sent to the
6LBRs as above.
Shelby, et al. Expires February 4, 2011 [Page 35]
Internet-Draft ND Optimization for LLNs August 2010
-
- A router MUST NOT modify the Neighbor Cache as a result of receiving
- a Neighbor Solicitation with an ARO of Length=4.
-
8.2.4. 6LBR Receiving a special Neighbor Solicitation
When a 6LBR that implements the optional multihop DAD receives an NS
- from a 6LR, that is an NS that contains an ARO with Length = 4, then
- it MUST NOT verify that the hop limit is 255 as specified above.
- Then it proceeds to look for the Registration Address in the DAD
+ from a 6LR, then it MUST NOT verify that the hop limit is 255 as
+ specified above. Then it proceeds to look for the Registration Address in
the DAD
Table. If an entry is found and the recorded EUI-64 is different
than the EUI-64 in the ARO, then it returns an NA with the ARO Status
set to 1 ('Duplicate Address'). Otherwise it returns an NA with ARO
Status set to zero.
If no entry is found in the DAD Table and the Registration Lifetime
is non-zero, then an entry is created and the EUI-64 and Registered
@@ -1986,35 +1934,18 @@
In both of the above cases the ARO Status code is set to zero, and
the 6LBR forms an NA with the ARO copied from the NS to the NA. The
NA is sent back to the 6LR i.e., back to the source of the NS.
8.2.5. Processing a special Neighbor Advertisement
When a 6LR that implements the optional multihop DAD receives an NA
- from a 6LBR, that is an NS that contains an ARO with Length = 4, then
- it MUST NOT verify that the hop limit is 255 as specified above. If
- there is no Tentative Neighbor Cache entry matching the Registered
- address and EUI-64, then NA is silently ignored. Otherwise, the
- information from the 6LBR is used to form an NA to send to the host.
- The Status code is copied from the ARO received from the 6LBR to the
- ARO that is sent to the host.
-
- If the Status is non-zero indicating an error, then the Tentative
- Neighbor Cache entry for the Registered Address is removed.
- Otherwise it is made into a Registered Neighbor Cache entry.
-
- A router MUST NOT modify the Neighbor Cache as a result of receiving
- a Neighbor Advertisement with an ARO of Length=4, unless there is a
- Tentative Neighbor Cache entry matching the IPv6 address and EUI-64.
-
-
-
-
-
-
+ from a 6LBR, then it MUST NOT verify that the hop limit is 255 as
+ specified above. The information from the 6LBR is used to form an
+ NA to send to the host. The ARO being sent to the host is copied
+ from the ARO received from the 6LBR.
Shelby, et al. Expires February 4, 2011 [Page 36]
Internet-Draft ND Optimization for LLNs August 2010
8.2.6. Recovering from Failures
@@ -2154,16 +2085,20 @@
address as per [RFC4944]. As the network is unmanaged (M flag not
set in RA), the 6LN randomly chooses a 16-bit link-layer address and
forms a tentative IPv6 address from it.
4. Next the 6LN registers that address with one or more of its
default routers by sending a unicast NS message with an ARO
containing its tentative global IPv6 address to register, the
- registration lifetime and its EUI-64. An SLLAO is also included with
- the link-layer address corresponding to the address being registered.
+ registration lifetime, its EUI-64, and the link-layer address
+ corresponding to the address being registered. The SLLAO here corresponds
+ to the link-layer address associated with the IPv6 address from which
+ this unicast NS was sent. The unicast NS is sent from a link-local
+ address corresponding with the EUI-64 in the ARO, per section 7 of
+ [RFC4944].
If a successful (status 0) NA message is received the address can
then be used and the 6LN assumes it has been successfully checked for
duplicates. If a duplicate address (status 1) NA message is
received, the 6LN then removes the temporary IPv6 address and 16-bit
link-layer address and goes back to step 3. If a neighbor cache full
(status 2) message is received, the 6LN attempts to register with
another default router, or if none, goes back to step 2.
@@ -2338,14 +2273,22 @@
context distribution and extensive contributions to earlier versions
of the draft, Geoff Mulligan for suggesting the use of Address
Registration as part of existing IPv6 Neighbor Discovery messages,
and Mathilde Durvy for helping to clarify router interaction.
14. Changelog
+
+ Changes from -12 to -CO:
+
+ o Temporary Neighbor Cache Entry removed
+
+ o Addition of LLA to ARO
+
+ o Always sent NS from IPv6 address based on EUI-64.
Changes from -11 to -12:
Shelby, et al. Expires February 4, 2011 [Page 42]
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
