Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE

rfc-editor@rfc-editor.org Mon, 22 March 2021 05:32 UTC

To: rahul.ietf@gmail.com, pthubert@cisco.com, rabinarayans@huawei.com, zhencao.ietf@gmail.com
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, dominique.barthel@orange.com, mariainesrobles@googlemail.com, aretana.ietf@gmail.com, jgs@juniper.net, martin.vigoureux@nokia.com, consultancy@vanderstok.org, aretana.ietf@gmail.com, c310@rfc-editor.org
Content-type: text/plain; charset="UTF-8"
Message-Id: <20210322053225.CBB91F4075A@rfc-editor.org>
Date: Sun, 21 Mar 2021 22:32:25 -0700
Subject: Re: [C310] AUTH48 [LB]: RFC 9009 <draft-ietf-roll-efficient-npdao-18.txt> NOW AVAILABLE
Precedence: list

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.

1) <!-- [rfced] Author lists: Would Rahul Jadhav and Rabi Narayan
Sahoo like their names on the first page to appear as "R. Jadhav"
and "R. Sahoo" or "R.A. Jadhav" and "R.N. Sahoo"? We ask because
we do not see a precedent in published RFCs and would like to know
how their names should appear on the first page of this RFC, as well
as future RFCs.

Listings in the XML file:
<author fullname="Rahul Arvind Jadhav" initials="R.A." role="editor" surname="Jadhav">
...
<author fullname="Rabi Narayan Sahoo" initials="R.N." surname="Sahoo">

Original text output (xml2rfc v2):
ROLL R. Jadhav, Ed.
Internet-Draft Huawei
Intended status: Standards Track P. Thubert
Expires: October 17, 2020 Cisco
R. Sahoo
...

Current text output (xml2rfc v3):
Internet Engineering Task Force (IETF) R.A. Jadhav, Ed.
Request for Comments: 9009 Huawei
Category: Standards Track P. Thubert
ISSN: 2070-1721 Cisco
R.N. Sahoo
... -->

2)

3) <!-- [rfced] Section 1.1: This sentence did not parse. We updated
as follows. If this is incorrect, please clarify "has target with
lifetime 0 used".

Original:
No-Path DAO (NPDAO):
A DAO message which has target with lifetime 0 used for the
purpose of route invalidation.

Currently:
No-Path DAO (NPDAO):
A DAO message that has a target with a lifetime of 0. Used for
the purpose of route invalidation. -->

4) <!-- [rfced] Section 1.3: It appears that NPDAO messaging, as opposed
to an NPDAO, is important. We updated this title accordingly.
Please let us know if this is incorrect.

Original:
1.3. Why Is NPDAO Important?

Currently:
1.3. Why Is NPDAO Messaging Important? -->

5) <!-- [rfced] Section 1.3: As (D), (E), and (F) appear to be distinct
destinations per Figure 1, we changed "destination" to "destinations" in this
sentence. Also, please note that we added spaces between what appear to be
node entries.

Please let us know if anything is incorrect. For example, were
spaces between the node entries left out because paths, as opposed to
separate nodes, are indicated?

Original:
In the above example, when
Node (D) switches parent, the route updates needs to be done for the
routing tables entries of (C),(H),(A),(G), and (B) with destination
(D),(E) and (F).

Currently:
In the above example,
when Node (D) switches its parent, route updates need to be done for
the routing table entries of (C), (H), (A), (G), and (B) with
destinations (D), (E), and (F).

If paths are indicated, then possibly (per Section 1.2):
In the above example,
when Node (D) switches its parent, route updates need to be done for
the routing table entries of (C)-(H)-(A)-(G) and for (B) with
destinations (D)-(E) and (F). -->

6) <!-- [rfced] Section 2.2: Does "on its behalf" mean "on its own
behalf" (i.e., Node (D)) or "on behalf of the parent"?

Original:
In the example topology, when Node (D) switches its parent, Node (D)
generates an NPDAO on its behalf. -->

7) <!-- [rfced] Section 4.2: Please review the following, and let us
know any concerns.

a) This document cited an older version of
[I-D.ietf-roll-unaware-leaves]. What used to be Figure 3
("RPL Status Format") is now Figure 6 in the latest version of
[I-D.ietf-roll-unaware-leaves]. We updated this sentence
accordingly. Please let us know any concerns.

Original:
Value 195 represents 'E' and 'A' bit in RPL Status to be set as per
Figure 3 of [I-D.ietf-roll-unaware-leaves] with the lower 6 bits with
value 3 indicating 'Moved' as per Table 1 of [RFC8505].

Currently:
Value 195 represents the 'E' and 'A' bits in RPL Status, to be set as
per Figure 6 of [RFC9010], with the lower 6 bits with value 3
indicating 'Moved' as per Table 1 of [RFC8505].

b) Because RFC 8505 was not listed in the References section, we
added it, as it appears to be required for this document. Please
let us know if we should create an Informative References section for
it, as opposed to listing it as a Normative Reference.

Currently:
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. -->

8) <!-- [rfced] Figures 2, 3, and 4: The alignment of the "ruler"
numbers in these figures is unusual, in that the numbers appear over
the "plus" ("+") signs instead of the dashes ("-"). Please let us
know if we should correct the alignment per more common usage in
RFCs (e.g., RFC 6550).

9) <!-- [rfced] Sections 4.3.4 and 5.2: Please let us know how the
items related to "DCO-ACK Status" (diagram, description, and the
table in Section 5.2) should be updated. We received email from
IANA, dated 4 January 2021, that says the following regarding
the "Destination Cleanup Object Acknowledgment (DCO-ACK) Status"
registry:

"That registry was deleted on October 28th per Alvaro and Pascal
[IANA #1181404]."

Also, it now appears that "Unqualified acceptance", as listed here
and in Section 5.2, is now defined by RFC 9010 <draft-ietf-roll-unaware-leaves>
instead of this document. Please advise.

Original:
| RPLInstanceID |D| Flags | DCOSequence | DCO-ACK Status|
...
DCO-ACK Status: Indicates the completion. A value of 0 is defined as
unqualified acceptance in this specification. A value of 1 is
defined as "No routing-entry for the Target found". The remaining
status values are reserved as rejection codes.
...
Section 5.2 in its entirety

Currently (updated the "No routing entry" information per
<https://www.iana.org/assignments/rpl/>):
DCO-ACK Status: Indicates completion. A value of 0 is defined as
unqualified acceptance in this specification. A value of 1 is
defined as "No routing entry". The remaining Status values are
reserved as rejection codes.

Please review carefully, the following appears in the IANA registry. From the
text, I expect both Unqualified acceptance and Unqualified rejection to appear
in the same registry.

RPL Non-Rejection Status registry:
0 Unqualified acceptance

RPL Rejection Status registry:
0 Unqualified rejection
1 No routing entry
-->

10) <!-- [rfced] Section 4.4: We had trouble following this sentence.
We updated it as follows. Please review, and let us know if anything
is incorrect.

Original:
2. The RPLInstanceID and DODAGID fields of a DCO message MUST be the
same value as that of the DAO message in response to which the
DCO is generated on the common ancestor node.

Currently:
2. The RPLInstanceID and DODAGID fields of a DCO message MUST have
the same values as those contained in the DAO message in response
to which the DCO is generated on the common ancestor node. -->

11) <!-- [rfced] Section 4.4: Please clarify the meaning of
"in context to".

Original:
5. A node receiving a unicast DCO message MUST verify the stored
Path Sequence in context to the given target. -->

12) <!-- [rfced] Section 4.4: As it appears that "more fresh" and "newer"
mean the same thing, we added "i.e.," ("that is") to this sentence.
Please let us know if this is incorrect (i.e., does the text mean
"is more fresh or is newer"?).

Original:
If the stored Path
Sequence is more fresh, newer than the Path Sequence received in
the DCO, then the DCO MUST be dropped.

Currently:
If the stored Path
Sequence is more fresh, i.e., newer than the Path Sequence
received in the DCO, then the DCO MUST be dropped. -->

13) <!-- [rfced] Section 4.4: Does "it" in this sentence refer to the
DCOSequence values (in which case it should be "those values"), or
something else?

Original:
The scope of DCOSequence values is unique to the node which generates
it. -->

14) <!-- [rfced] Section 4.6.1: To what does "its" refer in this
sentence - the nodes, in which case perhaps the text should be
"all of their DAO messages' Transit Information options", or
something else?

Original:
Thus for route
invalidation the dependent nodes may choose to always set the 'I'
flag in all its DAO message's Transit Information Option.

Possibly:
Thus, for route invalidation, the dependent nodes may choose to
always set the 'I' flag in all of their DAO messages' Transit
Information options. -->

15) <!-- [rfced] Section 4.6.2: This sentence does not parse. Please
let us know how the text can be corrected.

Original:
If there are 6LRs en-route DCO message path which do
not support this document, then the route invalidation for
corresponding targets may not work or may work partially i.e., only
part of the path supporting DCO may be invalidated. -->

16) <!-- [rfced] Section 4.6.3: For ease of the reader, we expanded
several abbreviations in this sentence. Please review, and let us
know if any of the expansions are incorrect.

Original:
For networks supporting only MP2P and P2MP
flows, such as in AMI and telemetry applications, the 6LRs may not be
very keen to invalidate routes, unless they are highly memory-
constrained.

Currently:
For networks supporting only Multi-Point to
Point (MP2P) and Point-to-Multipoint (P2MP) flows, such as in
Advanced Metering Infrastructure (AMI) and telemetry applications,
the 6LRs may not be very keen to invalidate routes, unless they are
highly memory constrained. -->

17) <!-- [rfced] Section 4.6.4: As it appears that RFC 6550, as opposed
to the protocol, mentions the use of an NPDAO, we added the citation
accordingly and rephrased the text. Please review carefully, and let
us know if anything is incorrect.

Original:
Subsequently when
route invalidation has to be initiated, RPL mentions use of NPDAO
which can be initiated with an updated Path Sequence to all the
parent nodes through which the route is to be invalidated.

Currently:
Subsequently, when
route invalidation has to be initiated, an NPDAO, which can be
initiated with an updated Path Sequence to all the parent nodes
through which the route is to be invalidated, can be used; see
[RFC6550]. -->

18) <!-- [rfced] Section 6: All tables except the table at the beginning
of the IANA Considerations section have a title. May we add a title
as follows?

Suggested:
Table 1: New Codes for DCO and DCO-ACK Messages -->

19) <!-- [rfced] Sections 6.1, 6.2, and 6.3: Because "IETF Review"
is a special term defined by RFC 8126, we have cited RFC 8126 in
these sections and added RFC 8126 to the list of Normative
References. Please let us know if you approve.
Last login: Sat Mar 20 16:03:03 on ttys002
SandyGiozasMBP2:~ sandyginoza$ /Users/sandyginoza/Connect.command ; exit;
Password:
Last login: Sat Mar 20 16:03:00 2021 from 2603:8000:9603:b513:a43a:79b6:9996:a61a
Have a lot of fun...

Some men are all right in their place -- if they only the knew the right places!
-- Mae West

sginoza@rfcpa:~> cd ~/inc-work
sginoza@rfcpa:~/inc-work> dir cluster310*
-rw-rw-r-- 1 kcm rfc 3949 Mar 19 17:09 cluster310.aq
-rw-rw-r-- 1 sginoza rfc 3950 Mar 19 17:00 cluster310.aq~
-rw-rw-r-- 1 leb rfc 1348754 Jan 29 09:30 cluster310.catfile
-rw-rw-r-- 1 sginoza rfc 2093 Mar 15 12:32 cluster310.docs
-rw-rw-r-- 1 sginoza rfc 2088 Mar 8 08:52 cluster310.docs~
-rw-rw-r-- 1 leb rfc 721398 Mar 19 14:29 cluster310-edited.catfile
-rw-rw-r-- 1 leb rfc 667780 Mar 19 14:34 cluster310-edited-minus-npdao.catfile
-rw-rw-r-- 1 sginoza rfc 465 Mar 17 13:59 cluster310expedite.aq
-rw-rw-r-- 1 sginoza rfc 253 Mar 17 13:57 cluster310expedite.aq~
-rw-rw-r-- 1 sginoza rfc 290616 Mar 19 17:08 cluster310-expedited.txt
-rw-rw-r-- 1 jm2 rfc 2232 Feb 15 10:02 cluster310-IEEE802154-refs.txt
-rw-rw-r-- 1 kcm rfc 288552 Apr 23 2020 cluster310_kc.original
-rw-rw-r-- 1 sginoza rfc 312825 Mar 15 13:15 cluster310.original
-rw-rw-r-- 1 ahagens rfc 269183 Nov 16 12:26 cluster310_prepub.txt
-rw-rw-r-- 1 ahagens rfc 281481 Nov 16 12:26 cluster310_prepub.xml
-rw-rw-r-- 1 kcm rfc 19578 Jan 26 14:44 cluster310.terms
-rw-rw-r-- 1 kcm rfc 5082 Jun 26 2020 cluster310.terms~
sginoza@rfcpa:~/inc-work> ed cluster310-expedite
cluster310-edited.catfile cluster310-expedited.txt
cluster310-edited-minus-npdao.catfile cluster310-IEEE802154-refs.txt
sginoza@rfcpa:~/inc-work> ed cluster310-expedited.txt
sginoza@rfcpa:~/inc-work> show "link-layer" | wc
1008 10079 89327
sginoza@rfcpa:~/inc-work> show "Link-Layer" | wc
139 1250 11435
sginoza@rfcpa:~/inc-work> ed rfc9008.xml
sginoza@rfcpa:~/inc-work> ed rfc9009.xml
sginoza@rfcpa:~/inc-work> ed rfc9010.xml
sginoza@rfcpa:~/inc-work> show "Link-Layer address" | wc
6 47 381
sginoza@rfcpa:~/inc-work> show "Link-Layer address"
Searching RFCs in the 6000s, 7000s, and 8000s (case sensitive)...
rfcs-done/rfc6355.txt: DUID-LLT - the Link-Layer address of one of the device's network
rfcs-done/rfc6355.txt: DUID-LL - the Link-Layer address of one of the device's network
rfcs-done/rfc8163.txt: 1: for Source Link-Layer address.
rfcs-done/rfc8163.txt: 2: for Target Link-Layer address.
DONE
sginoza@rfcpa:~/inc-work> show "link-layer address"
Searching RFCs in the 6000s, 7000s, and 8000s (case sensitive)...
rfcs-done/rfc6059.txt: o The combination of the link-layer address and the link-local IPv6
rfcs-done/rfc6059.txt: | | link-layer address. |
rfcs-done/rfc6059.txt: (link-local + link-layer address of the router) and consists of at
rfcs-done/rfc6059.txt: neighbor solicitations to the link-layer address of the router stored
rfcs-done/rfc6059.txt: The probing node SHOULD include the source link-layer address option
rfcs-done/rfc6059.txt: The probing node SHOULD NOT include the source link-layer address
rfcs-done/rfc6085.txt: address is mapped into an Ethernet link-layer address. This document
rfcs-done/rfc6105.txt: (addresses) or L2 (link-layer address, port number) legitimate
rfcs-done/rfc6105.txt: o Allowed/Disallowed link-layer address of the RA sender
rfcs-done/rfc6164.txt: addresses to link-layer addresses.
rfcs-done/rfc6250.txt: information (e.g., the link-layer address of the destination) on
rfcs-done/rfc6274.txt: address to the corresponding link-layer address (for example, by
rfcs-done/rfc6274.txt: the corresponding IP address into a link-layer address, the attacked
rfcs-done/rfc6274.txt: use of that link-layer address. At the point in which the mapping
rfcs-done/rfc6275.txt: link-layer address
rfcs-done/rfc6275.txt: agent MUST send it to the mobile node's link-layer address (retrieved
rfcs-done/rfc6275.txt: link-layer address for this IP address on behalf of the mobile node.
rfcs-done/rfc6275.txt: specifying the home agent's link-layer address.
rfcs-done/rfc6275.txt: link-layer address, causing it to transmit any future packets
rfcs-done/rfc6275.txt: link-layer address change for the mobile node's address through use
rfcs-done/rfc6275.txt: Advertisement giving the home agent's own link-layer address as the
rfcs-done/rfc6275.txt: link-layer address for the specified Target Address. In addition,
rfcs-done/rfc6275.txt: to learn the home agent's link-layer address, since the home agent
rfcs-done/rfc6275.txt: learned the home agent's link-layer address from a Source Link-Layer
rfcs-done/rfc6275.txt: link-layer address, instructing its home agent to no longer serve as
rfcs-done/rfc6275.txt: sender's link-layer address. It is necessary to reply, since sending
rfcs-done/rfc6275.txt: advertise the mobile node's own link-layer address for its own home
rfcs-done/rfc6275.txt: node's link-layer address. The mobile node MUST multicast such a
rfcs-done/rfc6282.txt: destination link-layer addresses on intermediate hops.
rfcs-done/rfc6282.txt: [IEEE802.15.4] link-layer addresses to IIDs for both short and
rfcs-done/rfc6324.txt: source address as the link-layer address corresponding to the
rfcs-done/rfc6324.txt: address of the host as the link-layer address of the delegated IPv6
rfcs-done/rfc6324.txt: IPv4 address of the non-advertising router as the link-layer address
rfcs-done/rfc6459.txt: contain no link-layer address information. However, some operating
rfcs-done/rfc6459.txt: is made to believe that the underlying link has link-layer addresses.
rfcs-done/rfc6459.txt: completes when the UE tries to resolve the link-layer address of the
rfcs-done/rfc6459.txt: resolve the link-layer address of the GGSN, thus stalling all IPv6
rfcs-done/rfc6475.txt: "This variable indicates the link-layer address value
rfcs-done/rfc6475.txt: technologies where there is no link-layer address,
rfcs-done/rfc6496.txt: determined, the link-layer header and the link-layer address
rfcs-done/rfc6496.txt: update a cached link-layer address created securely by means of
rfcs-done/rfc6496.txt: described in [RFC4861], containing its own link-layer address (HA_LL)
rfcs-done/rfc6496.txt: PMIPv6 domain, with its own link-layer address as the source link-
rfcs-done/rfc6496.txt: the source link-layer address to the address of the outgoing
rfcs-done/rfc6496.txt: interface, changing source link-layer addresses contained in the
rfcs-done/rfc6496.txt: destination link-layer address as the address in the neighbor entry
rfcs-done/rfc6496.txt: proxied RA messages, etc. Note that besides link-layer addresses and
rfcs-done/rfc6496.txt: and a proxy, including different link-layer addresses, may be
rfcs-done/rfc6543.txt: use a fixed link-local address and a fixed link-layer address on any
rfcs-done/rfc6543.txt: link-layer address on any of their access links that they share with
rfcs-done/rfc6543.txt: the use of a fixed link-local and a fixed link-layer address, it did
rfcs-done/rfc6543.txt: link-layer address SHOULD be used by the mobile access gateway in
rfcs-done/rfc6543.txt: link-layer addresses as documented in Section 6.9.3 of the base Proxy
rfcs-done/rfc6543.txt: same set of link-local and link-layer address values beyond a single
rfcs-done/rfc6572.txt: information such as a MN's Interface ID, link-layer address, or NAI,
rfcs-done/rfc6575.txt: to resolve IP addresses to link-layer addresses. For instance, in
rfcs-done/rfc6575.txt: o Recording the IPv6 interface addresses and CE link-layer addresses
rfcs-done/rfc6575.txt: order to translate between different link-layer addresses. If a
rfcs-done/rfc6575.txt: Router Discovery message contains a link-layer address, then the PE
rfcs-done/rfc6575.txt: MAY also use this message to discover the link-layer address and IPv6
rfcs-done/rfc6575.txt: link-layer address of the local CE and be able to use it when
rfcs-done/rfc6575.txt: also wish to monitor the source link-layer address of data packets
rfcs-done/rfc6575.txt: link-layer address.
rfcs-done/rfc6575.txt: and any link-layer address provided. The packet MUST then be
rfcs-done/rfc6575.txt: link-layer address option is present, the PE MUST remove it. The PE
rfcs-done/rfc6575.txt: MAY substitute an appropriate link-layer address option, specifying
rfcs-done/rfc6575.txt: the link-layer address of the PE interface attached to the local AC.
rfcs-done/rfc6575.txt: the source link-layer address with the link-layer address of the
rfcs-done/rfc6575.txt: the far-end CE's IP address and the link-layer address of the PE
rfcs-done/rfc6575.txt: appropriate link-layer address option that specifies the link-
rfcs-done/rfc6575.txt: link-layer address provided. The packet MUST then be forwarded over
rfcs-done/rfc6575.txt: far-end CE. If a source link-layer address option is present, the PE
rfcs-done/rfc6575.txt: address option, specifying the link-layer address of the PE interface
rfcs-done/rfc6575.txt: to substitute a link-layer address option may mean that the local AC
rfcs-done/rfc6575.txt: has no valid link-layer address with which to transmit data packets.
rfcs-done/rfc6575.txt: determine and learn the IPv6 addresses and the link-layer addresses.
rfcs-done/rfc6575.txt: The Source and Target link-layer addresses are copied from the
rfcs-done/rfc6575.txt: o If it has not learned at least one IPv6 and link-layer address of
rfcs-done/rfc6575.txt: until the PE learns an IPv6 and link-layer address from the local
rfcs-done/rfc6575.txt: be forwarded to the local CE after modifying the link-layer address
rfcs-done/rfc6575.txt: from the INA; and the link-layer address is that of the local AC on
rfcs-done/rfc6575.txt: present, the link-layer address of the CE. It MUST then be forwarded
rfcs-done/rfc6575.txt: If a source link-layer address option is present, the PE MUST remove
rfcs-done/rfc6575.txt: it. The PE MAY substitute a source link-layer address option
rfcs-done/rfc6575.txt: specifying the link-layer address of its local AC. The packet is
rfcs-done/rfc6575.txt: present, the link-layer address of the CE. It MUST then be forwarded
rfcs-done/rfc6575.txt: If a source link-layer address option is present, the PE MUST remove
rfcs-done/rfc6575.txt: it. The PE MAY substitute a source link-layer address option
rfcs-done/rfc6575.txt: specifying the link-layer address of its local AC. If an MTU option
rfcs-done/rfc6575.txt: particular, just because a PE has learned a link-layer address for
rfcs-done/rfc6575.txt: link-layer address for IPv4 traffic until that fact is confirmed by
rfcs-done/rfc6575.txt: while the other does not, the IP address to link-layer address
rfcs-done/rfc6583.txt: a node determines the link-layer address of a neighbor given only
rfcs-done/rfc6583.txt: correct link-layer address to use in the destination field of the
rfcs-done/rfc6583.txt: Discovery [RFC4861] protocol to determine the link-layer address of
rfcs-done/rfc6583.txt: control both the rate of link-layer address resolution requests
rfcs-done/rfc6606.txt: (or 16-bit short) link-layer addresses instead of IP addresses. A
rfcs-done/rfc6621.txt: no need for associating link-layer address information with 1-hop
rfcs-done/rfc6706.txt: link-layer address of the client AERO node as the link-layer address
rfcs-done/rfc6706.txt: with link-layer address L2(A). The intermediate router ('A') next
rfcs-done/rfc6706.txt: link-layer address L2(B). Node ('B') configures a default route with
rfcs-done/rfc6706.txt: link-layer address L2(D). Node ('D') configures a default route with
rfcs-done/rfc6706.txt: local network-layer address L3(F) and with link-layer address L2(F).
rfcs-done/rfc6706.txt: Note that on links in which link-layer address spoofing is possible,
rfcs-done/rfc6706.txt: link-layer address of the egress node).
rfcs-done/rfc6706.txt: (i.e., the link-layer address of the ingress node).
rfcs-done/rfc6706.txt: link-layer address of the intermediate router).
rfcs-done/rfc6706.txt: link-layer address of the egress node).
rfcs-done/rfc6706.txt: link-layer address of the ingress node).
rfcs-done/rfc6706.txt: them to the last-known link-layer address of EUN node ('E') as a
rfcs-done/rfc6706.txt: When an ingress node needs to change its link-layer address, it
rfcs-done/rfc6706.txt: node's new link-layer address. The egress then returns a new AERO
rfcs-done/rfc6706.txt: When an egress node needs to change its link-layer address, it
rfcs-done/rfc6706.txt: changing the link-layer address. Any ingress node that receives the
rfcs-done/rfc6706.txt: router. The egress then changes the link-layer address, and it sends
rfcs-done/rfc6706.txt: for mobility and link-layer address change considerations when it
rfcs-done/rfc6706.txt: AERO links must be protected against link-layer address spoofing
rfcs-done/rfc6706.txt: link-layer address spoofing attacks are possible if the source can
rfcs-done/rfc6775.txt: A LoWPAN can use two types of link-layer addresses: 16-bit short
rfcs-done/rfc6775.txt: the routing protocol carries the link-layer addresses of the
rfcs-done/rfc6775.txt: directly reachable and their corresponding link-layer addresses.
rfcs-done/rfc6775.txt: all-routers anycast link-layer address, then that MAY be used to
rfcs-done/rfc6775.txt: IPv6 address to its associated link-layer address. As all prefixes
rfcs-done/rfc6775.txt: using a link-layer address. Thus, a host can reduce memory usage by
rfcs-done/rfc6775.txt: optimizing for this case and only storing link-layer address
rfcs-done/rfc6775.txt: information if it differs from the link-layer address corresponding
rfcs-done/rfc6775.txt: required so that the hosts will know the link-layer address of the
rfcs-done/rfc6775.txt: the NA, since the host already knows the router's link-layer address
rfcs-done/rfc6775.txt: each other's link-layer addresses. If the routing protocol used
rfcs-done/rfc6775.txt: others link-layer addresses. Thus, routers MAY multicast NSs for
rfcs-done/rfc6775.txt: based on the 6LN's EUI-64 link-layer address formed as per
rfcs-done/rfc6775.txt: was able to obtain the link-layer address of a router through its
rfcs-done/rfc6775.txt: link-layer address and forms a Tentative IPv6 address from it.
rfcs-done/rfc6775.txt: with the link-layer address corresponding to the address being
rfcs-done/rfc6775.txt: temporary IPv6 address and 16-bit link-layer address and goes
rfcs-done/rfc6775.txt: MAC64: EUI-64 address used as the link-layer address.
rfcs-done/rfc6775.txt: supports detecting link-layer addresses from the routing information
rfcs-done/rfc6788.txt: link-layer address of the AN that sent the tunneled Router
rfcs-done/rfc6820.txt: resolution. To determine the link-layer address of a given IP
rfcs-done/rfc6939.txt: for encoding the client link-layer address in DHCPv6 Relay-Forward
rfcs-done/rfc6939.txt: client's link-layer address in the DHCPv6 messages being sent towards
rfcs-done/rfc6939.txt: client link-layer address in the DHCPv4 message header. A DHCPv4
rfcs-done/rfc6939.txt: link-layer address type and the link-layer address, respectively.
rfcs-done/rfc6939.txt: The client link-layer address thus learned can be used by the DHCPv4
rfcs-done/rfc6939.txt: client link-layer address as one of the keys to build the DHCP client
rfcs-done/rfc6939.txt: The client link-layer address is such an identifier.
rfcs-done/rfc6939.txt: to communicate the client link-layer address to the DHCP server in
rfcs-done/rfc6939.txt: client's link-layer address. This presents a problem to an operator
rfcs-done/rfc6939.txt: client link-layer address explicitly will help the above mentioned
rfcs-done/rfc6939.txt: Further, having the client link-layer address in DHCPv6 will help by
rfcs-done/rfc6939.txt: | link-layer address (variable length) |
rfcs-done/rfc6939.txt: option-length: 2 + length of link-layer address
rfcs-done/rfc6939.txt: link-layer type: Client link-layer address type. The link-layer
rfcs-done/rfc6939.txt: link-layer address: Client link-layer address
rfcs-done/rfc6939.txt: link-layer address from the link-layer header of the DHCPv6 message.
rfcs-done/rfc6957.txt: It is assumed in this document that link-layer addresses on a point-
rfcs-done/rfc6957.txt: the correct link-layer address type on each segment. When the ND
rfcs-done/rfc6957.txt: the number of IPv6 addresses per link-layer address (possibly, but
rfcs-done/rfc6957.txt: inform its neighbors of a new link-layer address) for an IPv6 address
rfcs-done/rfc6957.txt: address of that entry, and Link-layer-CPE2 the link-layer address of
rfcs-done/rfc6957.txt: associated with a link-layer address other than Link-layer-CPE1,
rfcs-done/rfc6957.txt: but the link-layer address of the CPE is performing DAD (Link-layer-
rfcs-done/rfc6957.txt: The link-layer address of the interface on which the BNG
rfcs-done/rfc6957.txt: The link-layer address of the interface on which the BNG
rfcs-done/rfc6957.txt: and the associated link-layer address is Link-layer-CPE2. The
rfcs-done/rfc6959.txt: with the link-layer address in the datagram. The degree of
rfcs-done/rfc6959.txt: corresponding link-layer address can be discarded. Of course, the
rfcs-done/rfc6959.txt: not have access to the link-layer address of the device from which
rfcs-done/rfc6959.txt: regard to link-layer address and IP address port bindings. The
rfcs-done/rfc6971.txt: or 64-bit Extended Unique Identifier (EUI-64) link-layer address
rfcs-done/rfc6971.txt: EUI-64 link-layer addresses, as specified in [RFC4944], if the
rfcs-done/rfc6971.txt: packet is sent; the link-layer address from that IP address is
rfcs-done/rfc6971.txt: The link-layer address is then used by L2 as the destination.
rfcs-done/rfc6971.txt: Address - A 16-bit short or EUI-64 link-layer address, as specified
rfcs-done/rfc7039.txt: o The combination of a host interface's link-layer address and a
rfcs-done/rfc7043.txt: resulting from indiscriminate publication of link-layer addresses in
rfcs-done/rfc7043.txt: indiscriminate publication of link-layer addresses in the DNS (see
rfcs-done/rfc7048.txt: able to handle the case when the link-layer address of the neighbor/
rfcs-done/rfc7048.txt: An NCE in the UNREACHABLE state retains the link-layer address, and
rfcs-done/rfc7048.txt: IPv6 packets continue to be sent to that link-layer address. But in
rfcs-done/rfc7048.txt: Different link-layer address than cached". There we need to add
rfcs-done/rfc7048.txt: packets to the recorded link-layer address.
rfcs-done/rfc7048.txt: retransmission to be able to handle a link-layer address change for
rfcs-done/rfc7048.txt: in a link-layer address, i.e., the case when a host or a router
rfcs-done/rfc7048.txt: changes its link-layer address while keeping the same IPv6 address.
rfcs-done/rfc7059.txt: of the hosts are used as link-layer addresses in the same way that
rfcs-done/rfc7066.txt: There are no link-layer addresses on the 3GPP cellular link
rfcs-done/rfc7066.txt: unlikely to contain the Target link-layer address option as there are
rfcs-done/rfc7066.txt: no link-layer addresses on the 3GPP cellular link technology.
rfcs-done/rfc7066.txt: (NUD) as specified in [RFC4861]. Note that the link-layer address
rfcs-done/rfc7066.txt: address option as there are no link-layer addresses. The cellular
rfcs-done/rfc7066.txt: absence of link-layer addressing, the address resolution can be
rfcs-done/rfc7136.txt: Universal and Group bits of an IEEE link-layer address are mapped
rfcs-done/rfc7136.txt: interface identifiers from an IEEE link-layer address, and it updates
rfcs-done/rfc7136.txt: of link-layer address, an equivalent transformation SHOULD be used.
rfcs-done/rfc7212.txt: link-layer addresses of the listeners. In short, they must be
rfcs-done/rfc7213.txt: for link-layer addressing of Ethernet frames carrying MPLS-TP
rfcs-done/rfc7213.txt: This document presents considerations for link-layer addressing of
rfcs-done/rfc7217.txt: o Since embedding the underlying link-layer address in the Interface
rfcs-done/rfc7217.txt: o Embedding the underlying link-layer address in the Interface
rfcs-done/rfc7217.txt: implementation might want to employ the link-layer address of the
rfcs-done/rfc7277.txt: parameters, and mappings of IP addresses to link-layer addresses. It
rfcs-done/rfc7277.txt: configured mappings from IP addresses to link-layer addresses.
rfcs-done/rfc7277.txt: known mappings from IP addresses to link-layer addresses.
rfcs-done/rfc7277.txt: autoconfiguration that embeds a link-layer address in its
rfcs-done/rfc7277.txt: link-layer addresses.
rfcs-done/rfc7277.txt: "The link-layer address of the neighbor node.";
rfcs-done/rfc7277.txt: link-layer addresses.
rfcs-done/rfc7277.txt: "The link-layer address of the neighbor node.";
rfcs-done/rfc7277.txt: link-layer addresses.
rfcs-done/rfc7277.txt: "The link-layer address of the neighbor node.";
rfcs-done/rfc7277.txt: link-layer addresses.
rfcs-done/rfc7277.txt: "The link-layer address of the neighbor node.";
rfcs-done/rfc7400.txt: bytes in the link-layer address of this particular capture (which are
rfcs-done/rfc7428.txt: G.9959 link-layer address, leading to a "link-layer-derived IPv6
rfcs-done/rfc7428.txt: link-layer address information
rfcs-done/rfc7428.txt: constructed from link-layer address information to save memory in
rfcs-done/rfc7428.txt: The method of constructing IIDs from the link-layer address obviously
rfcs-done/rfc7428.txt: into G.9959 link-layer addresses follows the general description in
rfcs-done/rfc7428.txt: currently responds. The link-layer address may change if the
rfcs-done/rfc7428.txt: [RFC4861] specifies how IPv6 nodes may resolve link-layer addresses
rfcs-done/rfc7428.txt: Some link layers use a 48-bit or 64-bit link-layer address that
rfcs-done/rfc7428.txt: link-layer address.
rfcs-done/rfc7436.txt: discover the link-layer address and IPv6 interface address(es)
rfcs-done/rfc7436.txt: The PE device MUST learn the link-layer address of the local CE and
rfcs-done/rfc7436.txt: also wish to monitor the source link-layer address of data packets
rfcs-done/rfc7436.txt: link-layer address. The PE device may also optionally learn a list
rfcs-done/rfc7513.txt: Send a message to verify that the link-layer address in the attached
rfcs-done/rfc7668.txt: address can be reconstructed from the link-layer address, used at the
rfcs-done/rfc7707.txt: The traditional SLAAC IIDs are based on the link-layer address of the
rfcs-done/rfc7707.txt: Therefore, the traditional IIDs based on link-layer addresses are
rfcs-done/rfc7707.txt: underlying link-layer address is generally desirable).
rfcs-done/rfc7707.txt: of IPv6 and link-layer addresses (without actively participating in
rfcs-done/rfc7707.txt: and the SAVI [RFC6620] cache of IPv6 and link-layer addresses. SNMP
rfcs-done/rfc7819.txt: permanent link-layer address of the network interface that the client
rfcs-done/rfc7819.txt: link-layer address during its first boot. Even if the administrator
rfcs-done/rfc7819.txt: enables link-layer address randomization, it is likely that it was
rfcs-done/rfc7819.txt: unobfuscated link-layer address will likely end up being announced as
rfcs-done/rfc7819.txt: the client identifier, even if the link-layer address has changed (or
rfcs-done/rfc7819.txt: the original link-layer address in the client identifier will also
rfcs-done/rfc7819.txt: link-layer address in the DHCP message header. A DHCP message header
rfcs-done/rfc7819.txt: address type and the link-layer address, respectively. The 'chaddr'
rfcs-done/rfc7824.txt: physical link-layer address, this information is disclosed to the
rfcs-done/rfc7824.txt: are based on the link-layer address of one of the device's network
rfcs-done/rfc7824.txt: link-layer address. It is commonly implemented in most popular
rfcs-done/rfc7824.txt: most implementations will use the available link-layer address during
rfcs-done/rfc7824.txt: link-layer address will likely end up being announced as the client
rfcs-done/rfc7824.txt: DUID, even if the link-layer address has changed (or even if being
rfcs-done/rfc7824.txt: the last four octets of the link-layer address. In most cases, that
rfcs-done/rfc7824.txt: means that merely two bytes are missing for a full link-layer addres
rfcs-done/rfc7824.txt: The client link-layer address option [RFC6939] is used by first-hop
rfcs-done/rfc7824.txt: DHCPv6 relays to provide the client's link-layer address towards the
rfcs-done/rfc7824.txt: message in the client link-layer address option, in relayed DHCPv6
rfcs-done/rfc7824.txt: configured to use client's link-layer address as Subscriber-ID.
rfcs-done/rfc7824.txt: the client link-layer address option, and by parsing the Client
rfcs-done/rfc7824.txt: ID option, client link-layer address option or Vendor-specific
rfcs-done/rfc7844.txt: randomizing other potential identifications like link-layer addresses
rfcs-done/rfc7844.txt: such as link-layer addresses are "randomized", so that the devices
rfcs-done/rfc7844.txt: negating the benefits of link-layer address randomization. This is
rfcs-done/rfc7844.txt: prominent being link-layer addresses, a.k.a. MAC addresses. For
rfcs-done/rfc7844.txt: consider the linkage between link-layer addresses, DHCP identifiers,
rfcs-done/rfc7844.txt: Per connection: Configure a random link-layer address at the time of
rfcs-done/rfc7844.txt: link-layer address for the same network -- different, of course,
rfcs-done/rfc7844.txt: Time interval: Change the link-layer address at regular time
rfcs-done/rfc7844.txt: In practice, there are many reasons to keep the link-layer address
rfcs-done/rfc7844.txt: changing the link-layer address requires dropping the existing Wi-Fi
rfcs-done/rfc7844.txt: The anonymity profiles pretty much assume that the link-layer addres
rfcs-done/rfc7844.txt: For example, if the link-layer address changes and the DHCP
rfcs-done/rfc7844.txt: and new link-layer addresses, either by listening to DHCP traffic or
rfcs-done/rfc7844.txt: but the link-layer address remains constant, the old and new
rfcs-done/rfc7844.txt: construct DHCP identifiers from the current link-layer address,
rfcs-done/rfc7844.txt: deriving most identifiers from the link-layer address and by
rfcs-done/rfc7844.txt: in which someone monitors link-layer addresses and identities used in
rfcs-done/rfc7844.txt: [WiFiRadioFingerprinting]. No amount of link-layer address
rfcs-done/rfc7844.txt: harder to deploy than just recording link-layer addresses with a
rfcs-done/rfc7844.txt: There are downsides to randomizing link-layer addresses and DHCP
rfcs-done/rfc7844.txt: procedures that rely on tracking link-layer addresses. Even if this
rfcs-done/rfc7844.txt: frequency of link-layer address randomization. Suppose, for example,
rfcs-done/rfc7844.txt: that many devices would get new random link-layer addresses at short
rfcs-done/rfc7844.txt: materialized by the assignment of a randomized link-layer address to
rfcs-done/rfc7844.txt: should still use link-layer address randomization to hide from
rfcs-done/rfc7844.txt: changed, particularly if the link-layer address is reset by a
rfcs-done/rfc7844.txt: link-layer address.
rfcs-done/rfc7844.txt: location or with a different link-layer address. This risk exists
rfcs-done/rfc7844.txt: previously connected, and if the link-layer address did not change,
rfcs-done/rfc7844.txt: Hardware addresses, called "link-layer addresses" in many RFCs, can
rfcs-done/rfc7844.txt: independent of the link-layer address. This is particularly useful
rfcs-done/rfc7844.txt: link-layer address will not be nullified by the Client Identifier
rfcs-done/rfc7844.txt: point-to-point link, in which case there is no link-layer address
rfcs-done/rfc7844.txt: the link-layer address changes and that the obfuscated host name will
rfcs-done/rfc7844.txt: not reveal the underlying link-layer address. The construction
rfcs-done/rfc7844.txt: a secure hash of a local secret and of the link-layer address that
rfcs-done/rfc7844.txt: specified in [RFC3315]: link-layer address plus time (DUID-LLT),
rfcs-done/rfc7844.txt: link-layer addresses, DHCPv6 clients MUST use DUID format number 3 --
rfcs-done/rfc7844.txt: link-layer address. The value of the link-layer address should be
rfcs-done/rfc7844.txt: link-layer addresses, clients that want to protect their privacy
rfcs-done/rfc7844.txt: the current link-layer address, because the reuse of old values
rfcs-done/rfc7844.txt: link-layer address remains constant.
rfcs-done/rfc7844.txt: link-layer address.
rfcs-done/rfc7844.txt: solution is to remove all stored addresses when a link-layer address
rfcs-done/rfc7844.txt: have been explicitly assigned through the current link-layer address.
rfcs-done/rfc7844.txt: they will be discarded when the link-layer address is changed. They
rfcs-done/rfc7844.txt: FQDN by combining a host name derived from the link-layer address and
rfcs-done/rfc7844.txt: For example, when a client changes its link-layer address and
rfcs-done/rfc7844.txt: anonymity profiles to that of link-layer address randomization.
rfcs-done/rfc7934.txt: addresses are used by particular link-layer addresses (for example,
rfcs-done/rfc7934.txt: link-layer address (e.g., if the link layer uniquely identifies or
rfcs-done/rfc8064.txt: cases, and recommends against embedding stable link-layer addresses
rfcs-done/rfc8064.txt: typically embeds a stable link-layer address (e.g., an IEEE LAN MAC
rfcs-done/rfc8064.txt: based on a link-layer address may offer some advantages. For
rfcs-done/rfc8064.txt: underlying link-layer address.
rfcs-done/rfc8064.txt: layer addresses (e.g., whether the link-layer address is ephemeral or
rfcs-done/rfc8064.txt: link-layer addresses in IPv6 IIDs.
rfcs-done/rfc8064.txt: against embedding stable link-layer addresses in IPv6 Interface
rfcs-done/rfc8064.txt: containing a link-layer address. For example, this document does not
rfcs-done/rfc8064.txt: addresses (e.g., by embedding a link-layer address that is
rfcs-done/rfc8064.txt: that embed a stable link-layer address in the IID. In particular,
rfcs-done/rfc8064.txt: IIDs based on a node's link-layer address.
rfcs-done/rfc8064.txt: link-layer addresses are mitigated.
rfcs-done/rfc8065.txt: link-layer address.
rfcs-done/rfc8065.txt: name, or fixed link-layer address. Indeed, the default address
rfcs-done/rfc8065.txt: called "Short Addresses", or both, as link-layer addresses. We
rfcs-done/rfc8065.txt: link-layer addresses with enough entropy compared to the link
rfcs-done/rfc8065.txt: addresses derived from such link-layer addresses would be roughly
rfcs-done/rfc8065.txt: addresses) can be mitigated if the link-layer address itself changes
rfcs-done/rfc8065.txt: link lifetime. Specifying that randomized link-layer addresses
rfcs-done/rfc8161.txt: hop's link-layer address.
rfcs-done/rfc8161.txt: header includes the IPv6 next hop's link-layer address.
rfcs-done/rfc8161.txt: o Source Link-Layer Address - link-layer address of DUT interface
rfcs-done/rfc8180.txt: destination and source link-layer addresses (e.g., short, extended,
rfcs-done/rfc8273.txt: same link-layer address every time a host connects, any remote party
rfcs-done/rfc8273.txt: networks, it SHOULD ensure that its link-layer address is
rfcs-done/rfc8302.txt: IP address, and source link-layer address in ND.
rfcs-done/rfc8302.txt: address, and target link-layer address in ND.
rfcs-done/rfc8344.txt: link-layer addresses.
rfcs-done/rfc8344.txt: autoconfiguration that embeds a link-layer address in its
rfcs-done/rfc8344.txt: link-layer addresses.
rfcs-done/rfc8344.txt: "The link-layer address of the neighbor node.";
rfcs-done/rfc8344.txt: link-layer addresses.
rfcs-done/rfc8344.txt: "The link-layer address of the neighbor node.
rfcs-done/rfc8344.txt: link-layer address of the neighbor has not yet been
rfcs-done/rfc8344.txt: link-layer addresses.
rfcs-done/rfc8344.txt: "The link-layer address of the neighbor node.";
rfcs-done/rfc8344.txt: link-layer addresses.
rfcs-done/rfc8344.txt: "The link-layer address of the neighbor node.";
rfcs-done/rfc8344.txt: link-layer address of the neighbor has not yet been
rfcs-done/rfc8376.txt: be configured to embed their link-layer addresses in the IID by
rfcs-done/rfc8386.txt: autoconfiguration and link-layer address lookup. Also, application
rfcs-done/rfc8415.txt: parse a DUID to obtain a client's link-layer address is unreliable,
rfcs-done/rfc8415.txt: link-layer address as when it generated its DUID. Also, such an
rfcs-done/rfc8415.txt: value, followed by the link-layer address of any one network
rfcs-done/rfc8415.txt: hardware types, the link-layer address is stored in canonical form,
rfcs-done/rfc8415.txt: . link-layer address (variable length) .
rfcs-done/rfc8415.txt: as that interface provides a globally unique link-layer address for
rfcs-done/rfc8415.txt: interface's link-layer address was used to generate the DUID-LLT.
rfcs-done/rfc8415.txt: . link-layer address (variable length) .
rfcs-done/rfc8415.txt: as that interface provides a unique link-layer address and is
rfcs-done/rfc8415.txt: interface's link-layer address was used to generate the DUID.
rfcs-done/rfc8415.txt: connected network interface with a link-layer address and do not have
rfcs-done/rfc8505.txt: link-layer address of the 6LN that owns the address.
rfcs-done/rfc8505.txt: the same Link-Local Address but different link-layer addresses. In
rfcs-done/rfc8691.txt: IEEE link-layer address, are significant. The details of this
rfcs-done/rfc8691.txt: resolve the link-layer address using a unicast exchange.
rfcs-done/rfc8885.txt: option is used for exchanging the link-layer address of the DLIF to
rfcs-done/rfc8885.txt: A variable length field containing the link-layer address of the
rfcs-done/rfc8885.txt: link-layer addresses. On certain access links where the link-
rfcs-done/rfc8928.txt: be derived from the link-layer address of the device (using the
rfcs-done/rfc8928.txt: instance, its Source link-layer address. Such verification protects
rfcs-done/rfc8928.txt: and link-layer addresses in an attempt to obfuscate its multiple
rfcs-done/rfc8929.txt: link-layer address as the Target Link-Layer Address (TLLA) in the
rfcs-done/rfc8929.txt: case, the link-layer address and the mobility of the Registering
rfcs-done/rfc8929.txt: advertises the link-layer address of the Registering Node in the
rfcs-done/rfc8929.txt: interface, link-local address, and link-layer address (LLA) of the
rfcs-done/rfc8929.txt: as a unicast link-layer frame to the link-layer address of the
rfcs-done/rfc8929.txt: In this mode, it is not required that the link-layer addresses of the
rfcs-done/rfc8929.txt: resolved the address with the 6BBR link-layer address, maintaining
rfcs-done/rfc8929.txt: resolve the link-layer address of the new 6BBR. The old 6BBR SHOULD
rfcs-done/rfc8929.txt: approach, the link-layer address of the LLN devices and their
rfcs-done/rfc8930.txt: the Layer 2 sender. Associated with the link-layer address of the
rfcs-done/rfc8930.txt: * a unique identifier of node A (e.g., node A's link-layer address).
rfcs-done/rfc8930.txt: addresses), node A must use the same link-layer address to send all
rfcs-done/rfc8930.txt: with the interface and the link-layer address of node A for which
rfcs-done/rfc8930.txt: with the interface and the link-layer address of node A for which
rfcs-done/rfc8930.txt: * the link-layer address that node B uses as the source to forward
rfcs-done/rfc8930.txt: * the interface and the link-layer address of the next-hop C that is
rfcs-done/rfc8930.txt: entry contains at a minimum the link-layer address of the
rfcs-done/rfc8931.txt: use several link-layer addresses to increase its indexing capacity.
rfcs-done/rfc8931.txt: source IPv6 address when it matches the link-layer address [RFC6282].
rfcs-done/rfc8931.txt: source link-layer address of the fragment, so together the link-layer
rfcs-done/rfc8931.txt: swapped at each hop as the source link-layer address changes.
rfcs-done/rfc8931.txt: link-layer address and the Datagram_Tag.
rfcs-done/rfc8931.txt: previous hop as known by its link-layer address in the VRB. The
rfcs-done/rfc8931.txt: 2 information associated with it (interface and link-layer address).
rfcs-done/rfc8931.txt: In route-over mode, the source and destination link-layer addresses
rfcs-done/rfc8931.txt: link-layer address.
rfcs-done/rfc8931.txt: next interface, source and next-hop link-layer addresses, and the
rfcs-done/rfc8931.txt: interface to the next hop, the link-layer address the router uses as
rfcs-done/rfc8931.txt: interface, previous-hop link-layer address, Datagram_Tag) found in
rfcs-done/rfc8931.txt: * The source and destination link-layer addresses are swapped from
rfcs-done/rfc8931.txt: indexed by the interface and destination link-layer address of the
rfcs-done/rfc8947.txt: devices may have their link-layer addresses assigned in an automated
rfcs-done/rfc8947.txt: link-layer address assignments where preassigned link-layer address
rfcs-done/rfc8947.txt: the new VM instances are assigned a link-layer address, but random
rfcs-done/rfc8947.txt: global link-layer address uniqueness for such devices, a link-layer
rfcs-done/rfc8947.txt: to handle link-layer address assignments.
rfcs-done/rfc8947.txt: link-layer address type, some of the details are specific to IEEE 802
rfcs-done/rfc8947.txt: specifics for other link-layer address types.
rfcs-done/rfc8947.txt: address block A number of consecutive link-layer addresses. An
rfcs-done/rfc8947.txt: link-layer addresses. See Section 11.1 for details
rfcs-done/rfc8947.txt: assign a block of link-layer addresses. See
rfcs-done/rfc8947.txt: server A node that manages link-layer address allocation and
rfcs-done/rfc8947.txt: globally unique link-layer address on any of its interfaces MUST NOT
rfcs-done/rfc8947.txt: switch it is connected to prohibits or restricts link-layer address
rfcs-done/rfc8947.txt: words, the device may support only assignment of link-layer addresses
rfcs-done/rfc8947.txt: A client that changes its link-layer address on an interface SHOULD
rfcs-done/rfc8947.txt: its neighbors of the new link-layer address quickly.
rfcs-done/rfc8947.txt: Note that if the client is releasing the link-layer address it is
rfcs-done/rfc8947.txt: to initiate DHCPv6 to provide an allocated link-layer address).
rfcs-done/rfc8947.txt: A server selects link-layer addresses to be assigned to an IA_LL
rfcs-done/rfc8947.txt: of the same link-layer address being used by more than one device.
rfcs-done/rfc8947.txt: For a client requesting a link-layer address directly from a server,
rfcs-done/rfc8948.txt: address block A number of consecutive link-layer addresses. An
rfcs-done/rfc8948.txt: link-layer addresses. Section 11.1 of [RFC8947]
rfcs-done/rfc8948.txt: assign a block of link-layer addresses. Section 11.2
rfcs-done/rfc8948.txt: server A node that manages link-layer address allocation and
rfcs-done/rfc8966.txt: derived from a link-layer address. (The protocol encoding is
rfcs-done/rfc8987.txt: link-layer addresses match.
DONE
sginoza@rfcpa:~/inc-work> !e
ed rfc9010.xml
sginoza@rfcpa:~/inc-work> grep "rendez-vous" cluster310-expedited.txt
sginoza@rfcpa:~/inc-work> ed rfc9010.xml
sginoza@rfcpa:~/inc-work> ed rfc9008.txt
sginoza@rfcpa:~/inc-work> ed rfc9009.txt
sginoza@rfcpa:~/inc-work> more rfc9008.original

ROLL Working Group M. Robles
Internet-Draft UTN-FRM/Aalto
Updates: 6553, 6550, 8138 (if approved) M. Richardson
Intended status: Standards Track SSW
Expires: July 19, 2021 P. Thubert
Cisco
January 15, 2021

Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6
encapsulation in the RPL Data Plane
draft-ietf-roll-useofrplinfo-44

Abstract

This document looks at different data flows through LLN (Low-Power
and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
and Lossy Networks) is used to establish routing. The document
enumerates the cases where RFC6553 (RPI Option Type), RFC6554
(Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is
required in data plane. This analysis provides the basis on which to
design efficient compression of these headers. This document updates
RFC6553 adding a change to the RPI Option Type. Additionally, this
document updates RFC6550 defining a flag in the DIO Configuration
option to indicate about this change and updates RFC8138 as well to
consider the new Option Type when the RPL Option is decompressed.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 19, 2021.

Robles, et al. Expires July 19, 2021 [Page 1]
^L
sginoza@rfcpa:~/inc-work> more rfc9009.original

ROLL R. Jadhav, Ed.
Internet-Draft Huawei
Intended status: Standards Track P. Thubert
Expires: October 17, 2020 Cisco
R. Sahoo
Z. Cao
Huawei
April 15, 2020

Efficient Route Invalidation
draft-ietf-roll-efficient-npdao-18

Abstract

This document explains the problems associated with the current use
of NPDAO messaging and also discusses the requirements for an
optimized route invalidation messaging scheme. Further a new
proactive route invalidation message called as "Destination Cleanup
Object" (DCO) is specified which fulfills requirements of an
optimized route invalidation messaging.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

This Internet-Draft will expire on October 17, 2020.

Jadhav, et al. Expires October 17, 2020 [Page 1]
^L
sginoza@rfcpa:~/inc-work> more rfc9010.original

ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems
Updates: 6550, 6775, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman
Expires: 26 July 2021 22 January 2021

Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-30

Abstract

This specification updates RFC6550, RFC6775, and RFC8505. It
provides a mechanism for a host that implements a routing-agnostic
interface based on 6LoWPAN Neighbor Discovery to obtain reachability
services across a network that leverages RFC6550 for its routing
operations.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

This Internet-Draft will expire on 26 July 2021.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.

Thubert & Richardson Expires 26 July 2021 [Page 1]
^L
sginoza@rfcpa:~/inc-work> ed rfc9009.xml
sginoza@rfcpa:~/inc-work> makeall rfc9009.xml
Created file rfc9009.txt
Created file rfc9009.html
Created file rfc9009.pdf
sginoza@rfcpa:~/inc-work> ed rfc9008.xml
sginoza@rfcpa:~/inc-work> makeall rfc9008.xml
Created file rfc9008.txt
Created file rfc9008.html
Created file rfc9008.pdf
sginoza@rfcpa:~/inc-work> more rfc9009.txt

Internet Engineering Task Force (IETF) R.A. Jadhav, Ed.
Request for Comments: 9009 Huawei
Category: Standards Track P. Thubert
ISSN: 2070-1721 Cisco
R.N. Sahoo
Z. Cao
Huawei
March 2021

Efficient Route Invalidation

Abstract

This document explains the problems associated with the current use
of No-Path Destination Advertisement Object (NPDAO) messaging and
also discusses the requirements for an optimized route invalidation
messaging scheme. Further, this document specifies a new proactive
route invalidation message called the "Destination Cleanup Object"
(DCO), which fulfills requirements for optimized route invalidation
messaging.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9009.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction
1.1. Requirements Language and Terminology
1.2. Current NPDAO Messaging
1.3. Why Is NPDAO Messaging Important?
2. Problems with Current NPDAO Messaging
2.1. Lost NPDAO Due to Link Break to the Previous Parent
2.2. Invalidating Routes of Dependent Nodes
2.3. Possible Route Downtime Caused by Asynchronous Operation of
the NPDAO and DAO
3. Requirements for NPDAO Optimization
3.1. Req. #1: Remove Messaging Dependency on the Link to the
sginoza@rfcpa:~/inc-work> more rfc9008.txt

Internet Engineering Task Force (IETF) M.I. Robles
Request for Comments: 9008 UTN-FRM/Aalto
Updates: 6550, 6553, 8138 M. Richardson
Category: Standards Track SSW
ISSN: 2070-1721 P. Thubert
Cisco
March 2021

Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-
IPv6 Encapsulation in the RPL Data Plane

Abstract

This document looks at different data flows through Low-Power and
Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power
and Lossy Networks) is used to establish routing. The document
enumerates the cases where RPL Packet Information (RPI) Option Type
(RFC 6553), RPL Source Route Header (RFC 6554), and IPv6-in-IPv6
encapsulation are required in the data plane. This analysis provides
the basis upon which to design efficient compression of these
headers. This document updates RFC 6553 by adding a change to the
RPI Option Type. Additionally, this document updates RFC 6550 by
defining a flag in the DODAG Information Object (DIO) Configuration
option to indicate this change and updates RFC 8138 as well to
consider the new Option Type when the RPL Option is decompressed.

Status of This Memo

This is an Internet Standards Track document.

Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9008.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction
1.1. Overview
2. Terminology and Requirements Language
3. RPL Overview
4. Updates to RFC 6550, RFC 6553, and RFC 8138
4.1. Updates to RFC 6550
sginoza@rfcpa:~/inc-work> ed rfc9010.xml
sginoza@rfcpa:~/inc-work> grep "root node" cluster310-expedited.txt
root node.
nodes and all traffic flows through the root node. Thus, there is no
sginoza@rfcpa:~/inc-work> grep "Root Node" cluster310-expedited.txt
sginoza@rfcpa:~/inc-work> grep "Root node" cluster310-expedited.txt
that is optimized to reach a Root node, as opposed to along the
sginoza@rfcpa:~/inc-work> ed rfc9010.xml
sginoza@rfcpa:~/inc-work> makeall rfc9010.xml
Created file rfc9010.txt
Created file rfc9010.html
Created file rfc9010.pdf
sginoza@rfcpa:~/inc-work> v3post rfc9008
rm: cannot remove 'rfc9008-xmldiff.html': No such file or directory
rm: cannot remove 'rfc9008-alt-diff.html': No such file or directory
The files have been posted here:
https://www.rfc-editor.org/authors/rfc9008.txt
https://www.rfc-editor.org/authors/rfc9008.html
https://www.rfc-editor.org/authors/rfc9008.pdf
https://www.rfc-editor.org/authors/rfc9008.xml
https://www.rfc-editor.org/authors/rfc9008-diff.html
https://www.rfc-editor.org/authors/rfc9008.original.v2v3.xml
https://www.rfc-editor.org/authors/rfc9008.form.xml
https://www.rfc-editor.org/authors/rfc9008-xmldiff1.html
https://www.rfc-editor.org/authors/rfc9008-xmldiff2.html
sginoza@rfcpa:~/inc-work> v3post rfc9009
rm: cannot remove 'rfc9009-diff.html': No such file or directory
rm: cannot remove 'rfc9009-xmldiff.html': No such file or directory
rm: cannot remove 'rfc9009-alt-diff.html': No such file or directory
The files have been posted here:
https://www.rfc-editor.org/authors/rfc9009.txt
https://www.rfc-editor.org/authors/rfc9009.html
https://www.rfc-editor.org/authors/rfc9009.pdf
https://www.rfc-editor.org/authors/rfc9009.xml
https://www.rfc-editor.org/authors/rfc9009-diff.html
https://www.rfc-editor.org/authors/rfc9009.original.v2v3.xml
https://www.rfc-editor.org/authors/rfc9009.form.xml
https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html
https://www.rfc-editor.org/authors/rfc9009-xmldiff2.html
sginoza@rfcpa:~/inc-work> v3post rfc9010
rm: cannot remove 'rfc9010-xmldiff.html': No such file or directory
rm: cannot remove 'rfc9010-alt-diff.html': No such file or directory
gawk: fatal: cannot open file `rfc9010xml2.original.xml' for reading (No such file or directory)
cp: cannot stat 'rfc9010xml2.original.xml': No such file or directory
gawk: fatal: cannot open file `/tmp/rfcdiff-12343/1/rfc9010xml2.original.xml' for reading (No such file or directory)
cmp: EOF on 1/rfc9010xml2.original.xml
cp: cannot stat 'rfc9010.original.v2v3.xml': No such file or directory
The files have been posted here:
https://www.rfc-editor.org/authors/rfc9010.txt
https://www.rfc-editor.org/authors/rfc9010.html
https://www.rfc-editor.org/authors/rfc9010.pdf
https://www.rfc-editor.org/authors/rfc9010.xml
https://www.rfc-editor.org/authors/rfc9010-diff.html
https://www.rfc-editor.org/authors/rfc9010.original.v2v3.xml
https://www.rfc-editor.org/authors/rfc9010.form.xml
https://www.rfc-editor.org/authors/rfc9010-xmldiff1.html
https://www.rfc-editor.org/authors/rfc9010-xmldiff2.html
https://www.rfc-editor.org/authors/rfc9010-alt-diff.html
sginoza@rfcpa:~/inc-work> dir *9009*
-rw-rw-r-- 1 sginoza rfc 101583 Mar 21 21:25 rfc9009-diff.html
-rw-rw-r-- 1 sginoza rfc 77551 Mar 8 09:15 rfc9009.form.xml
-rw-rw-r-- 1 sginoza rfc 131962 Mar 21 21:07 rfc9009.html
-rw-rw-r-- 1 sginoza rfc 56849 Mar 8 09:15 rfc9009.original
-rw-rw-r-- 1 sginoza rfc 77127 Mar 8 09:15 rfc9009.original.v2v3.xml
-rw-rw-r-- 1 sginoza rfc 192802 Mar 21 21:07 rfc9009.pdf
-rw-rw-r-- 1 sginoza rfc 53682 Mar 21 21:07 rfc9009.txt
-rw-rw-r-- 1 sginoza rfc 82471 Mar 19 15:24 rfc9009.xml
-rw-rw-r-- 1 sginoza rfc 82618 Mar 19 15:00 rfc9009.xml~
-rw-rw-r-- 1 sginoza rfc 56849 Mar 8 09:15 rfc9009xml2.original
-rw-rw-r-- 1 sginoza rfc 77348 Mar 8 09:15 rfc9009xml2.original.xml
-rw-rw-r-- 1 sginoza rfc 77348 Mar 8 09:15 rfc9009xml2.xml
-rw-rw-r-- 1 sginoza rfc 169575 Mar 21 21:25 rfc9009-xmldiff1.html
-rw-rw-r-- 1 sginoza rfc 555669 Mar 21 21:25 rfc9009-xmldiff2.html
sginoza@rfcpa:~/inc-work> ed rfc9009.xml
sginoza@rfcpa:~/inc-work> ed rfc9009.xml
sginoza@rfcpa:~/inc-work> makeall rfc9009.xml
Created file rfc9009.txt
Created file rfc9009.html
Created file rfc9009.pdf
sginoza@rfcpa:~/inc-work> v3post rfc9009
rm: cannot remove 'rfc9009-xmldiff.html': No such file or directory
rm: cannot remove 'rfc9009-alt-diff.html': No such file or directory
The files have been posted here:
https://www.rfc-editor.org/authors/rfc9009.txt
https://www.rfc-editor.org/authors/rfc9009.html
https://www.rfc-editor.org/authors/rfc9009.pdf
https://www.rfc-editor.org/authors/rfc9009.xml
https://www.rfc-editor.org/authors/rfc9009-diff.html
https://www.rfc-editor.org/authors/rfc9009.original.v2v3.xml
https://www.rfc-editor.org/authors/rfc9009.form.xml
https://www.rfc-editor.org/authors/rfc9009-xmldiff1.html
https://www.rfc-editor.org/authors/rfc9009-xmldiff2.html
sginoza@rfcpa:~/inc-work> get-comments2.py rfc9008.xml > rfc9008.aq
sginoza@rfcpa:~/inc-work> ed rfc9008.aq
sginoza@rfcpa:~/inc-work> get-comments2.py rfc9009.xml > rfc9009.aq
sginoza@rfcpa:~/inc-work> get-comments2.py rfc9010.xml > rfc9010.aq
sginoza@rfcpa:~/inc-work> more rfc9008.original

Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6
encapsulation in the RPL Data Plane
draft-ietf-roll-useofrplinfo-44

Abstract

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

This Internet-Draft will expire on July 19, 2021.

Robles, et al. Expires July 19, 2021 [Page 1]
^L
sginoza@rfcpa:~/inc-work> more rfc9009.original

ROLL R. Jadhav, Ed.
Internet-Draft Huawei
Intended status: Standards Track P. Thubert
Expires: October 17, 2020 Cisco
R. Sahoo
Z. Cao
Huawei
April 15, 2020

Efficient Route Invalidation
draft-ietf-roll-efficient-npdao-18

Abstract

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

This Internet-Draft will expire on October 17, 2020.

Jadhav, et al. Expires October 17, 2020 [Page 1]
^L
sginoza@rfcpa:~/inc-work> more rfc9010.original

ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems
Updates: 6550, 6775, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman
Expires: 26 July 2021 22 January 2021

Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-30

Abstract

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

This Internet-Draft will expire on 26 July 2021.

Thubert & Richardson Expires 26 July 2021 [Page 1]
^L
sginoza@rfcpa:~/inc-work> more rfc9008.original

Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6
encapsulation in the RPL Data Plane
draft-ietf-roll-useofrplinfo-44

Abstract

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

This Internet-Draft will expire on July 19, 2021.

Robles, et al. Expires July 19, 2021 [Page 1]
^L
sginoza@rfcpa:~/inc-work> more rfc9009.original

ROLL R. Jadhav, Ed.
Internet-Draft Huawei
Intended status: Standards Track P. Thubert
Expires: October 17, 2020 Cisco
R. Sahoo
Z. Cao
Huawei
April 15, 2020

Efficient Route Invalidation
draft-ietf-roll-efficient-npdao-18

Abstract

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

This Internet-Draft will expire on October 17, 2020.

Jadhav, et al. Expires October 17, 2020 [Page 1]
^L
sginoza@rfcpa:~/inc-work> more rfc9010.original

ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems
Updates: 6550, 6775, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman
Expires: 26 July 2021 22 January 2021

Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-30

Abstract

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

This Internet-Draft will expire on 26 July 2021.

Thubert & Richardson Expires 26 July 2021 [Page 1]
^L
sginoza@rfcpa:~/inc-work> dir *9010*
-rw-rw-r-- 1 sginoza rfc 175373 Mar 21 21:25 rfc9010-alt-diff.html
-rw-rw-r-- 1 sginoza rfc 106889 Mar 8 09:15 rfc9010.alt-original
-rw-rw-r-- 1 sginoza rfc 10957 Mar 21 21:52 rfc9010.aq
-rw-rw-r-- 1 sginoza rfc 177514 Mar 21 21:25 rfc9010-diff.html
-rw-rw-r-- 1 sginoza rfc 105117 Mar 8 09:15 rfc9010.form.xml
-rw-rw-r-- 1 sginoza rfc 209692 Mar 21 21:24 rfc9010.html
-rw-rw-r-- 1 sginoza rfc 106896 Mar 8 09:15 rfc9010.original
-rw-rw-r-- 1 sginoza rfc 104386 Mar 8 09:15 rfc9010.original.xml
-rw-rw-r-- 1 sginoza rfc 350855 Mar 21 21:24 rfc9010.pdf
-rw-rw-r-- 1 sginoza rfc 99826 Mar 21 21:24 rfc9010.txt
-rw-rw-r-- 1 sginoza rfc 113721 Mar 21 21:24 rfc9010.xml
-rw-rw-r-- 1 sginoza rfc 113698 Mar 21 21:16 rfc9010.xml~
-rw-rw-r-- 1 sginoza rfc 124116 Mar 21 21:25 rfc9010-xmldiff1.html
-rw-rw-r-- 1 sginoza rfc 514744 Mar 21 21:25 rfc9010-xmldiff2.html
sginoza@rfcpa:~/inc-work> dir *9008*
-rw-rw-r-- 1 sginoza rfc 11748 Mar 21 21:51 rfc9008.aq
-rw-rw-r-- 1 sginoza rfc 279142 Mar 21 21:25 rfc9008-diff.html
-rw-rw-r-- 1 sginoza rfc 179343 Mar 8 09:10 rfc9008.form.xml
-rw-rw-r-- 1 sginoza rfc 320165 Mar 21 21:09 rfc9008.html
-rw-rw-r-- 1 sginoza rfc 149080 Mar 8 09:10 rfc9008.original
-rw-rw-r-- 1 sginoza rfc 173497 Mar 8 09:10 rfc9008.original.v2v3.xml
-rw-rw-r-- 1 sginoza rfc 440051 Mar 21 21:09 rfc9008.pdf
-rw-rw-r-- 1 sginoza rfc 137167 Mar 21 21:09 rfc9008.txt
-rw-rw-r-- 1 sginoza rfc 191375 Mar 21 21:09 rfc9008.xml
-rw-rw-r-- 1 sginoza rfc 191377 Mar 19 11:57 rfc9008.xml~
-rw-rw-r-- 1 sginoza rfc 149080 Mar 8 09:10 rfc9008xml2.original
-rw-rw-r-- 1 sginoza rfc 178515 Mar 8 09:10 rfc9008xml2.original.xml
-rw-rw-r-- 1 sginoza rfc 178515 Mar 8 09:10 rfc9008xml2.xml
-rw-rw-r-- 1 sginoza rfc 407067 Mar 21 21:25 rfc9008-xmldiff1.html
-rw-rw-r-- 1 sginoza rfc 1239777 Mar 21 21:25 rfc9008-xmldiff2.html
-rw-rw-r-- 1 rfc-ed rfc 191368 Mar 10 15:36 sandy9008.xml
sginoza@rfcpa:~/inc-work> dir *9009*
-rw-rw-r-- 1 sginoza rfc 16197 Mar 21 21:52 rfc9009.aq
-rw-rw-r-- 1 sginoza rfc 101583 Mar 21 21:50 rfc9009-diff.html
-rw-rw-r-- 1 sginoza rfc 77551 Mar 8 09:15 rfc9009.form.xml
-rw-rw-r-- 1 sginoza rfc 131962 Mar 21 21:48 rfc9009.html
-rw-rw-r-- 1 sginoza rfc 56849 Mar 8 09:15 rfc9009.original
-rw-rw-r-- 1 sginoza rfc 77127 Mar 8 09:15 rfc9009.original.v2v3.xml
-rw-rw-r-- 1 sginoza rfc 192802 Mar 21 21:48 rfc9009.pdf
-rw-rw-r-- 1 sginoza rfc 53682 Mar 21 21:48 rfc9009.txt
-rw-rw-r-- 1 sginoza rfc 82805 Mar 21 21:43 rfc9009.xml
-rw-rw-r-- 1 sginoza rfc 82471 Mar 19 15:24 rfc9009.xml~
-rw-rw-r-- 1 sginoza rfc 56849 Mar 8 09:15 rfc9009xml2.original
-rw-rw-r-- 1 sginoza rfc 77348 Mar 8 09:15 rfc9009xml2.original.xml
-rw-rw-r-- 1 sginoza rfc 77348 Mar 8 09:15 rfc9009xml2.xml
-rw-rw-r-- 1 sginoza rfc 169993 Mar 21 21:50 rfc9009-xmldiff1.html
-rw-rw-r-- 1 sginoza rfc 556833 Mar 21 21:50 rfc9009-xmldiff2.html
sginoza@rfcpa:~/inc-work> more rfc9010.original.xml
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr='trust200902' tocInclude="
true" updates='6550,6775,8505' obsoletes="" consensus="true" submissionType="IETF" xml:lang="e
n" version="3" docName="draft-ietf-roll-unaware-leaves-30" >

<front>

<title abbrev='RPL Unaware Leaves'>Routing for RPL Leaves</title>
<author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor'>
<organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization>
<address>
<postal>
<street>Building D</street>
<street>45 Allee des Ormes - BP1200 </street>
<city>Mougins - Sophia Antipolis</city>
<code>06254</code>
<country>France</country>
</postal>
<phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>

<author fullname='Michael C. Richardson' initials='M.' surname='Richardson'>
<organization abbrev='Sandelman'>Sandelman Software Works</organization>

<address>
<email>mcr+ietf@sandelman.ca</email>

<uri>http://www.sandelman.ca/</uri>
</address>
</author>

<date/>
<area>Routing</area>
<workgroup>ROLL</workgroup>

<abstract>
<t>
This specification updates RFC6550, RFC6775, and RFC8505. It provides a
mechanism for a host that implements a routing-agnostic interface based
on 6LoWPAN Neighbor Discovery to obtain reachability services across a
network that leverages RFC6550 for its routing operations.
</t>
</abstract>

sginoza@rfcpa:~/inc-work> htmlwdiff rfc9010.original.xml rfc9010.xml > rfc9010-xmldiff1.html
sginoza@rfcpa:~/inc-work> cp rfc9010-xmldiff1.html ~/in-notes/authors/
sginoza@rfcpa:~/inc-work> ed rfc9010.original.xml
sginoza@rfcpa:~/inc-work> dir ~/in-notes/authors/rfc9010
ls: cannot access '/home/sginoza/in-notes/authors/rfc9010': No such file or directory
sginoza@rfcpa:~/inc-work> dir ~/in-notes/authors/rfc9010*
-rw-rw-r-- 1 sginoza rfc 175373 Mar 21 21:25 /home/sginoza/in-notes/authors/rfc9010-alt-diff.html
-rw-rw-r-- 1 sginoza rfc 177514 Mar 21 21:25 /home/sginoza/in-notes/authors/rfc9010-diff.html
-rw-rw-r-- 1 sginoza rfc 105117 Mar 21 21:25 /home/sginoza/in-notes/authors/rfc9010.form.xml
-rw-rw-r-- 1 sginoza rfc 209692 Mar 21 21:25 /home/sginoza/in-notes/authors/rfc9010.html
-rw-rw-r-- 1 sginoza rfc 350855 Mar 21 21:25 /home/sginoza/in-notes/authors/rfc9010.pdf
-rw-rw-r-- 1 sginoza rfc 99826 Mar 21 21:25 /home/sginoza/in-notes/authors/rfc9010.txt
-rw-rw-r-- 1 sginoza rfc 113721 Mar 21 21:25 /home/sginoza/in-notes/authors/rfc9010.xml
-rw-rw-r-- 1 sginoza rfc 219754 Mar 21 22:10 /home/sginoza/in-notes/authors/rfc9010-xmldiff1.html
-rw-rw-r-- 1 sginoza rfc 514744 Mar 21 21:25 /home/sginoza/in-notes/authors/rfc9010-xmldiff2.html
sginoza@rfcpa:~/inc-work> htmlwdiff rfc9010.original.xml rfc9010.xml > rfc9010-xmldiff1.html
sginoza@rfcpa:~/inc-work> cp rfc9010-xmldiff1.html ~/in-notes/authors/
sginoza@rfcpa:~/inc-work> more rfc9008.aq
Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following quest
ions, which are also in the XML file.

1)

2) <!-- [rfced] Note that "M.I. Robles" currently appears in the document header.
Please let us know if you prefer "M. Robles" appear instead.

Current:
M.I. Robles
-->

3)

4) <!-- [rfced] FYI We have changed the hyphenation of the following
terms to make them consistent. Please let us know if any other changes
are necessary:

Original: Current:
RPL-aware-leaf RPL-aware leaf
RPL-aware-node RPL-aware node
RPL-unaware-leaf RPL-unaware leaf
RPL-unaware-node RPL-unaware node

Note that we have change instances of "not-RPL aware" to "RPL-unaware".
-->

5) <!-- [rfced] The following paragraph uses RECOMMEND, which is not an exact
match with one of the keywords defined by RFCs 2119 and 8174. Please
consider whether the following suggested update works so that RECOMMENDED
may be appropriately tagged as a <bcp14> keyword.

Current:
This specification updates [RFC6550] to RECOMMEND that external
targets are advertised using Non-Storing mode DAO messaging even in a
Storing mode network.

Perhaps:
This specification updates [RFC6550] to say that advertising external
targets using Non-Storing mode DAO messaging even in a Storing mode
network is RECOMMENDED.
-->

6) <!-- [rfced] In the following sentences, is perhaps "DODAG Configuration
option" meant instead of "DIO Configuration option"?

Current, Section 4.1.3:
In order to avoid a flag day caused by lack of interoperation between
nodes of the new RPI Option Type (0x23) and old RPI Option Type
(0x63), this section defines a flag in the DIO Configuration option,
to indicate when the new RPI Option Type can be safely used.

Section 4.2:
This option is controlled by the DIO Configuration option (Section 4.1.3).
-->

7) <!-- [rfced] We slightly modified the following direct quote since
RFC 6550 doesn't state "the unused bits MUST". From RFC 6550:

Flags: The 4-bits remaining unused in the Flags field are reserved
for flags. The field MUST be initialized to zero by the sender
and MUST be ignored by the receiver.

Original:
Currently, the DODAG Configuration option in [RFC6550] states: "the
unused bits MUST be initialized to zero by the sender and MUST be
ignored by the receiver".

Current:
Currently, the DODAG Configuration option in [RFC6550] states that the
unused bits "MUST be initialized to zero by the sender and MUST be
ignored by the receiver."
-->

8) <!-- [rfced] We update updated the following sentence to improve
readability. Please let us know if other changes are necessary.

Original:
But with
the current value of the Option Type, if a node in the Internet is
configured to process the Hop-by-Hop header, and if such node
encounters an option with the first two bits set to 01 and conforms
to [RFC8200], it will drop the packet.

Current:
However, with
sginoza@rfcpa:~/inc-work> ed rfc9008.aq
sginoza@rfcpa:~/inc-work> more rfc9008.aq
Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.

2) <!-- [rfced] Note that "M.I. Robles" currently appears in the document
header. Please let us know if you prefer "M. Robles" appear instead.

Current:
M.I. Robles
-->

3)

4) <!-- [rfced] FYI We have changed the hyphenation of the following
terms to make them consistent. Please let us know if any other changes
are necessary:

Original: Current:
RPL-aware-leaf RPL-aware leaf
RPL-aware-node RPL-aware node
RPL-unaware-leaf RPL-unaware leaf
RPL-unaware-node RPL-unaware node

Note that we have change instances of "not-RPL aware" to "RPL-unaware".
-->

5) <!-- [rfced] The following paragraph uses RECOMMEND, which is not an exact
match with one of the keywords defined by RFCs 2119 and 8174. Please consider
whether the following suggested update works so that RECOMMENDED may be
appropriately tagged as a <bcp14> keyword.