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
