<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.grey
{mso-style-name:grey;}
span.EmailStyle24
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:304437271;
mso-list-template-ids:1286393746;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:1728411944;
mso-list-type:hybrid;
mso-list-template-ids:1465555940 705077052 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">NBMA is not necessarily a one-size-fits-all category, and it looks like multiple proposals<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">are considering models for NBMA links. AERO and OMNI define an NBMA link model<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">for virtual links and do define the operation of IPv6 ND over those links in ways that<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">go beyond RFC5942. This is encouraged in RFC4861 where it says:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> “Unless specified otherwise (in a document that covers operating IP<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> over a particular link type) this document applies to all link types.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> However, because ND uses link-layer multicast for some of its<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> services, it is possible that on some link types (e.g., Non-Broadcast<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> Multi-Access (NBMA) links), alternative protocols or mechanisms to<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> implement those services will be specified (in the appropriate<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"> document covering the operation of IP over a particular link type).”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Fred<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> ipv6 [mailto:ipv6-bounces@ietf.org] <b>On Behalf Of
</b>Pascal Thubert (pthubert)<br>
<b>Sent:</b> Monday, June 01, 2020 7:27 AM<br>
<b>To:</b> Wes Beebee (wbeebee) <wbeebee=40cisco.com@dmarc.ietf.org>; Etienne-Victor Depasquale <edepa@ieee.org><br>
<b>Cc:</b> NANOG <nanog@nanog.org>; ipv6@ietf.org<br>
<b>Subject:</b> RE: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I take the “there was no NBMA” off, then, Wes, you’re correct. I’ll add a ref to RFC 5942 in section 4.4 that discusses the use of on-link flag.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Note that Hub and spoke is a very limited conception of NBMA. Think of an IOT network such as a RPL domain, or a frame relay network with OSPFv2 NBMA / P2MP models. It takes quite a bit more than resetting the on-link flag to enable IPv6
ND on those NBMA networks, though it is indeed necessary. This is what I tried to express too concisely.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Keep safe,<o:p></o:p></p>
<p class="MsoNormal">Pascal<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">PS For NBMA, RFC 4861 clearly says<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> non-broadcast multiple access (NBMA)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> - Redirect, Neighbor Unreachability Detection and<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> next-hop determination should be implemented as<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> described in this document. Address resolution,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> and the mechanism for delivering Router<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> Solicitations and Advertisements on NBMA links are<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> not specified in this document. Note that if<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> hosts support manual configuration of a list of<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> default routers, hosts can dynamically acquire the<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> link-layer addresses for their neighbors from<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""> Redirect messages.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Wes Beebee (wbeebee) <<a href="mailto:wbeebee=40cisco.com@dmarc.ietf.org">wbeebee=40cisco.com@dmarc.ietf.org</a>>
<br>
<b>Sent:</b> lundi 1 juin 2020 16:00<br>
<b>To:</b> Pascal Thubert (pthubert) <<a href="mailto:pthubert@cisco.com">pthubert@cisco.com</a>>; Etienne-Victor Depasquale <<a href="mailto:edepa@ieee.org">edepa@ieee.org</a>><br>
<b>Cc:</b> NANOG <<a href="mailto:nanog@nanog.org">nanog@nanog.org</a>>; <a href="mailto:ipv6@ietf.org">
ipv6@ietf.org</a><br>
<b>Subject:</b> Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">RFC 5942 outlines how NBMA works with Neighbor Discovery.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Using this RFC, IPv6 has been deployed in NBMA networks (DOCSIS) with 10 million+ subscribers without any problems.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3">
<![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>Wes<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">ipv6 <<a href="mailto:ipv6-bounces@ietf.org">ipv6-bounces@ietf.org</a>> on behalf of "Pascal Thubert (pthubert)" <<a href="mailto:pthubert=40cisco.com@dmarc.ietf.org">pthubert=40cisco.com@dmarc.ietf.org</a>><br>
<b>Date: </b>Sunday, May 31, 2020 at 8:29 AM<br>
<b>To: </b>Etienne-Victor Depasquale <<a href="mailto:edepa@ieee.org">edepa@ieee.org</a>><br>
<b>Cc: </b>NANOG <<a href="mailto:nanog@nanog.org">nanog@nanog.org</a>>, "<a href="mailto:ipv6@ietf.org">ipv6@ietf.org</a>" <<a href="mailto:ipv6@ietf.org">ipv6@ietf.org</a>><br>
<b>Subject: </b>Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Cool, that’s the whole point. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">With IPv6 ND as defined 20+ years ago there couldn’t be NBMA and there couldn’t be MLSN. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">We have changed that in IoT and we are now trying to generalize to all types of links.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">There’s a tentative to get the aforementioned draft adopted at 6MAN. If you found it useful please voice support !<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Take care,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="FR">Pascal<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="FR"><o:p> </o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="FR">Le 31 mai 2020 à 13:11, Etienne-Victor Depasquale <</span><span style="font-size:10.0pt"><a href="mailto:edepa@ieee.org"><span lang="FR">edepa@ieee.org</span></a></span><span lang="FR">> a écrit :<o:p></o:p></span></p>
</blockquote>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Pascal, thank you, the draft at <a href="https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/" target="_blank">
https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/</a> is very informative.
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">You hit the nail on the head with your suggestion of confusion between the congruence of link and subnet.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">However, I followed one of the references (RFC4903) in your draft and<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">it does not help that it (RFC4903) points to RFC4291's assertion that:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">"Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">RFC4903 further states that:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> "clearly, the notion of a multi-link subnet would be a change to the existing IP model.".<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I confess: your assertion in the draft that:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">"In Route-Over Multi-link subnets (MLSN) [RFC4903], <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">routers federate the links between nodes<o:p></o:p></p>
</div>
<p class="MsoNormal">that belong to the subnet, the subnet is not on-link and it extends<o:p></o:p></p>
<div>
<p class="MsoNormal">beyond any of the federated links"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">is news to me.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Etienne<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sat, May 30, 2020 at 1:39 PM Pascal Thubert (pthubert) <<a href="mailto:pthubert@cisco.com">pthubert@cisco.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Hello Etienne Victor <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Maybe you’re confusing link and a subnet?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">This is discussed at length here:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/" target="_blank">https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">RPL can route inside a subnet using host routes. This is how a multi link subnet can be made to work...<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Please let me know if the draft above helped and whether it is clear enough. The best way for that discussion would be to cc 6MAN.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="FR">Keep safe,<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="FR"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="FR">Pascal<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="FR"><o:p> </o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="FR">Le 30 mai 2020 à 10:03, Etienne-Victor Depasquale <</span><span style="font-size:10.0pt"><a href="mailto:edepa@ieee.org" target="_blank"><span lang="FR">edepa@ieee.org</span></a></span><span lang="FR">>
a écrit :<o:p></o:p></span></p>
</blockquote>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Thank you Carsten, and thank you Pacal. Your replies are valuable and packed with insight.
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'll wrap up with how I interpret RPL's behaviour in terms of IP hops.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On one hand, RFC6775 defines a route-over topology as follows:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">"A topology where hosts are connected to the 6LBR through the use of intermediate layer-3 (IP) routing. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Here, hosts are typically multiple IP hops away from a 6LBR. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The route-over topology typically consists of a 6LBR, a set of 6LRs, and hosts."<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">If RPL is route-over by definition, then RFC6775 would imply that there are typically multiple IP hops between a leaf and the border router.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On the other hand, there at least two contradictions (which I justify after stating them):<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(a) RFC6550 states that "RPL also introduces the capability to bind a subnet together with a common prefix and to route within that subnet."<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(b) Reduction of a DODAG to a single subnet prefix, albeit only only one parent-child relationship deep, is clearly shown at Contiki-NG's Github page (deep dive section).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The hinge on which my understanding revolves is that an IP hop traverses a router and ***results in a change of prefix of the link on which the packet travels*** :<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">--------<incoming packet; link prefix = p1>------><router> --------<outgoing packet; link prefix = p2>------><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">With RPL, the "hop" would look like as shown below:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> --------<incoming packet; link prefix = p1>------<router> --------<outgoing packet; link prefix = p1>------ <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There seems to be a change in the meaning associated with "IP hop". <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I guess that I can reconcile both cases through the observation that RPL actually does apply to a single, NBMA link and therefore the IP prefix ***is*** the same.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Then again, calling the RPL device involved in the packet forwarding by the name "router" feels like an uncomfortable stretch. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Don't routers sit at the meeting point of different layer 2 links?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Etienne<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, May 29, 2020 at 10:39 PM Pascal Thubert (pthubert) <<a href="mailto:pthubert@cisco.com" target="_blank">pthubert@cisco.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">Hello Etienne <br>
<br>
You may see ND as the host to * interface for any network and RPL as the router to router interface when the network is NBMA.<br>
<br>
Some of us cared about the interworking. <br>
<br>
Look at the RPL Unaware leaf I-draft and you’ll see that I’m sure.<br>
<br>
Keep safe,<br>
<br>
Pascal<br>
<br>
> Le 29 mai 2020 à 20:28, Carsten Bormann <<a href="mailto:cabo@tzi.org" target="_blank">cabo@tzi.org</a>> a écrit :<br>
> <br>
> Hi Etienne,<br>
> <br>
> I’m also not sure many of the classical network operators assembled in NANOG work with 6LoWPANs today, but I still can answer your question.<br>
> <br>
>> While trying to build a holistic view of LoWPANs, I'm consulting the IETF's informational and standards documents.<br>
>> <br>
>> I'm struck by the impression that, despite the significance of RFC6775's extension of Neighbor Discovery(ND) to low-power and lossy networks (LLNs),<br>
>> it is largely ignored by RFC6550 (RPL), with little to no reference to the ontological plane created in RFC6775's terminology section.<br>
> <br>
> Yes, you could say that.<br>
> <br>
> ND (Neighbor discovery) describes interfaces between hosts and between hosts and routers.<br>
> 6LoWPAN-ND does not use host-to-host interfaces (different from Ethernet, all traffic goes over routers, which RFC 4861 already forsaw in the L — on-link — bit, which isn’t set in 6LoWPAN-ND).<br>
> <br>
> RFC 6550 was completed at a time when many people who came in from the WSN (wireless sensor network) world thought they could get away with a network that is wholly composed of routers.<br>
> Even the “leaf” nodes in the RPL world were participating in the routing protocol and therefore didn’t really need a host-router interface. There was no separate host-router interface in that world, because there were no non-router hosts.<br>
> <br>
>> (a) router advertisements and router solicitations are substituted by DAG information objects (DIO) and DAG information solicitations (DIS)<br>
> <br>
> Right, DIO and DAO are router-to-router messages. If there are no hosts (and routers don’t bootstrap themselves as hosts), you don’t need ND.<br>
> <br>
>> (b) the terms "mesh-under" and "route-over" (widely cited), defined in RFC6775, are absent from RFC6550<br>
> <br>
> RFC6550 is route over by definition. Actually, the term was coined by the people working closely with the RPL development; RFC 6775 does appropriate it as 6LoWPAN-ND is applicable in either case.<br>
> <br>
>> (c) jarringly: RFC6775 describes the route-over topologies as multi-IP-hop, while RFC6550 gathers DODAG nodes within the confines of the same IPv6 prefix as their border router - no multiple IP hops.<br>
> <br>
> I’m not sure where you get this interpretation: RFC 6550 (RPL) is very much about IP hops.<br>
> Maybe you mean the address architecture that was defined explicitly in RFC 6775; RFC 6550 does not really say much about addresses.<br>
> <br>
> Note that the RPL people have since proceeded to (at least partially) embrace the host-router concept from the IP architecture; RFC 8505 is an update to RFC 6775 that makes 6LoWPAN-ND more palatable to RPL people.<br>
> <br>
> I have CCed Pascal Thubert who, as a co-author to all three RFCs, certainly will have another perspective on this.<br>
> <br>
> Grüße, Carsten<br>
> <o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif;color:#888888">Ing. Etienne-Victor Depasquale<br>
Assistant Lecturer<br>
Department of Communications & Computer Engineering<br>
Faculty of Information & Communication Technology<br>
University of Malta</span> <o:p></o:p></p>
<div>
<p class="MsoNormal">Web. <a href="https://www.um.edu.mt/profile/etiennedepasquale" target="_blank">https://www.um.edu.mt/profile/etiennedepasquale</a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Tahoma",sans-serif;color:#888888">Ing. Etienne-Victor Depasquale<br>
Assistant Lecturer<br>
Department of Communications & Computer Engineering<br>
Faculty of Information & Communication Technology<br>
University of Malta</span> <o:p></o:p></p>
<div>
<p class="MsoNormal">Web. <a href="https://www.um.edu.mt/profile/etiennedepasquale" target="_blank">https://www.um.edu.mt/profile/etiennedepasquale</a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>