Hi Adam ND operation is a link operation and what it does varies across link types. Simple as that.
That's hardly surprising. - RFC4861 is a form of reactive protocol that is optimized for a certain environment, namely many nodes, each one being able to see another one on a link, and a multicast capability. With a different constraint like few nodes and stricter forwarding/routing plane separation you might have ended up with a proactive protocol. - For ND, there are small variations (like omitting address resolution on certain P2P links) to larger ones (like inverse ND for FR/ATM). You'll note that RFC 3122 addresses a problem that is closer to 6LoWPAN because Frame Relay is non transitive. But we could hardly afford MARS and the multicast infra that goes with it. - Routing protocols are the same. They are optimized for certain assumptions. But whereas ND operates on a link with link level assumptions, routing protocols are optimized for network level operations, and depending on what you are doing at the network level at which you are operating, you have to select OSPF or RIP or OLSR or even BGP. Ipv6 is not broken. It is adaptable and extensible. Routing Protocols and ARP in IPv4 have similar causes and effects, though ND in its variations is incredibly richer than ARP. Pascal >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of Adam Dunkels >Sent: lundi 12 octobre 2009 16:41 >To: Carsten Bormann >Cc: 6lowpan >Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND > >Hi Carsten, > >these sounds like some serious architectural concerns with IPv6. Should >these really be dealt with by an adaptation layer that defines how to >transport IPv6 packets over a particular link layer? I am not too >accustomed to IETF practices, but isn't there a wg specifically for the >purpose of forwarding the IPv6 architecture (6man) where issues like >these should be raised? > >Also, one specific question: how would an IPv6 host deal with an >802.15.4 network interface if the IPv6 adaptation layer would require >changes to the core of the IPv6 stack to function properly? > >Thanks, > >/adam > >Carsten Bormann wrote: >> On Oct 12, 2009, at 14:47, Julien Abeille (jabeille) wrote: >> >>> the issues arised on lowpan networks as far as ND is concerned are not >>> huge >> >> >> [WG member hat] >> >> Julien, >> >> I'd like to know more about that. >> >> As far as I can see, certain parts of 4861-ND just DO NOT WORK on >> non-transitive networks. >> It's really as simple as that. >> >> So you either make 6LoWPANs transitive at huge cost, or you need >> something like 6LoWPAN-ND for those parts. >> (Or, you simply ignore that they don't work, which you mostly can for >> DAD; we didn't want to do that.) >> >> Please reread section 1, paragraph 2 of 4861 for its area of applicability. >> >> Gruesse, Carsten >> >> PS.: re the charter: >> Getting rid of 4861's address resolution by multicast is indeed just an >> optimization. >> I happen to believe it is a good one. We can (and should!) debate that. >> I would have argued to simply get rid of DAD as well, but there is the >> issue of counterfeiting. >> So we made a limited extension to make DAD work, which it doesn't for >> 4861-ND on non-transitive. >> etc. >> >> _______________________________________________ >> 6lowpan mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lowpan >> > >-- >Adam Dunkels <[email protected]>, +46707731614 >http://twitter.com/adunk | http://www.sics.se/~adam/ >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
