> If so, how is the Host determining the MTU? Each node sees an assured 1280 (or 1280-ENCAPS if an encapsulation header is included). If the node wants to try for larger sizes, it can use RFC4821.
When you configure an NBMA tunnel virtual overlay over the underlying wireless interfaces, there is no need for mutli-hop ND or DHCPv6 over the underlying interfaces. Instead, standard unicast single-hop ND and DHCPv6 are used over the NBMA tunnel virtual interface. Thanks - Fred [email protected] > -----Original Message----- > From: Alexandru Petrescu [mailto:[email protected]] > Sent: Monday, January 19, 2015 9:09 AM > To: Joe Touch; Templin, Fred L; Brian E Carpenter; [email protected] > Subject: Re: [Int-area] About draft-baccelli-manet-multihop-communication-04 > > Le 16/01/2015 21:58, Joe Touch a écrit : > > FYI, there's an RFC explaining all this already: 3819 > > I think this RFC can cover some of the issues raised in this draft, but > it deserves a better treatment of peculiarities of wireless subnetworks. > > For example, the hidden-terminal problem of wifi is not described in > this RFC, and no advice provided. Should WiFi non-wired IP routers > prefer to use 2 interfaces? > > Some wireless networks are special in other ways, not mentioned in the > draft, pushing the mobility support to an extreme. 802.11p is > completely silent (no link-layer messages other than announcing the > time) to allow fast connection establishment. If so, how is the Host > determining the MTU? It _MUST_ send an RS on these links, it is no > longer optional. That being the advice. Also, how to have NTP on these > links? > > NFC is a request-response link - should one use ICMP because small > footprint? Or TCP because reliable? > > These are some of the questions one may confront with. > > Alex > > > > > > Joe > > > > On 1/16/2015 12:04 PM, Templin, Fred L wrote: > >> +1 > >> > >>> -----Original Message----- > >>> From: Int-area [mailto:[email protected]] On Behalf Of Brian E > >>> Carpenter > >>> Sent: Friday, January 16, 2015 11:16 AM > >>> To: Alexandru Petrescu; [email protected] > >>> Subject: Re: [Int-area] About > >>> draft-baccelli-manet-multihop-communication-04 > >>> > >>> Alex, > >>> > >>>> but to improve the layers below IP such as to have IP run unmodified. > >>> > >>> In the general case that is impossible, because the SDO that develops > >>> the lower layer isn't interested. If the lower layer is intrinsically > >>> NBMA then for sure ARP or ND+DAD will not work as designed. If the lower > >>> layer doesn't support a physical MTU of at least 1280 IPv6 will not work > >>> as designed. So in the general case both an adaptation layer and an > >>> NBMA solution are required. And as you know, there are other "Ethernet" > >>> assumptions that don't apply in a low-power wireless scenario. > >>> > >>> Of course the goal is "IP over Everything" but that isn't the same as > >>> "Everything must be like Ethernet", which you seem to imply. > >>> > >>> In fact when you read draft-baccelli-manet-multihop-communication > >>> (and imagine what its security section will say when it's been > >>> written), I think the conclusion is that a great many things have > >>> to change, not in the IP packet format, but in the ecosystem > >>> currently provided by ARP/DHCP or RA/ND/DAD/SLAAC/DHCPv6. > >>> > >>> Brian > >>> > >>> _______________________________________________ > >>> Int-area mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/int-area > >> > >> _______________________________________________ > >> Int-area mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/int-area > >> > > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
