Inline. Parav
--- On Thu, 4/15/10, Alexandru Petrescu <[email protected]> wrote: > From: Alexandru Petrescu <[email protected]> > Subject: Re: deriving MAC address from destination Link local address without > Neighbor discovery > To: "Parav Pandit" <[email protected]> > Cc: "Ipv" <[email protected]> > Date: Thursday, April 15, 2010, 3:01 PM > Le 15/04/2010 07:55, Parav Pandit a > écrit : > > Hi, > > > > As per RFC 2464, Link local address for Ethernet based > interfaces > > are based on the EUI-64 (derived from the MAC > address). > > Right, that is probably a very widespread way of how the > link local > addresses are derived from a MAC address. > > There are many other ways, for example link negotiation > with PPP IPv6 > which for interfaces not having MAC addresses, like a 3G > phone... and > knowing that 3G IPv6 handheld computers (watches, phones, > pdas, pads, > netbooks) are potentially very numerous one may think it > could be as > widespread as the first. > > For these, deriving the MAC address from the link-local > address (w/o > doing ND) - will not work. > [Parav] You are absolutely correct. RFC 2464 will not be applicable to the examples that you gave because those are non-Ethernet interfaces and their respective link layer RFCs will be applicable but not 2464. > A case that comes to mind is 6LoWPAN's _some_ version of > "6LoWPAN > Neighbor Discovery" which requires the end node to do just > that: derive > the MAC address from the LL address. I believe this > intention wrongly > aimed. > > One shoudl try to identify why would one need to reversely > derive the > MAC address from the LL address of some neighbor? Is > it to save > messages? We can discuss that and see that sometimes > it's not needed to > save, better use point-to-point links. > > Why do you need to do this message-less reverse > resolution? > [PP] No. I would not like to prefer doing this reverse resolution. I am trying to find out and validate that if the IPv6 packet contains Link local address in IPv6 header but contains different MAC address (not related to EUI-64) in MAC header. Is this valid packet in ETHERNET networks? Its about protocol/RFC compliance. > > I have #3 questions based on this. > > > > In this case, when one Ethernet based host(from its > link-local > > source) tries to ping the other Ethernet based host, > it knows the > > Mac address implicitly (from the Link local address). > > In this case, if the problem is ping then the solution may > be > "ping -I iface" (-I specifies the outgoing interface). > > > 1. Why is it required to explicitly do the Neighbor > discovery for > > the link-local addresses? RFC 4861 says to do the > neighbor discovery > > even for link-local addresses. Correct me if my > understanding is > > incorrect. > > IMHO, one aspect is that it requires so in order to have > the most up to > date info about the other node. Sometimes nodes > change their LLs and > their MAC addresses (ifconfig does that). > > > 2. Does it mean that in Ethernet networks, interface > can have only > > one Link-local address? If not then we violate the RFC > 2464. > > I think I can do "ifconfig eth0 add fe80::1/64; ifconfig > eth0 add > fe80::2/64; echo $?" and see success, I suppose - have you > tried? [Parav] Yes, I have tried doing it on Linux systems and it allowed me! Even it allowed me entering LL address with prefix size other then 64 for Link local address. The second part made me doubt about the compliance (or loose compliance) to the RFC 2464. Seems like it is supporting the older obsolete RFC 1972 which allows such stuff. > > > 3. Does RFC 4941 Privacy extension for autoconf apply > to Ethernet > > interfaces? > > Well yes I believe so, I suppose I have it running on my PC > right now. > [Parav] May be because they follow desolate RFC 1972. > Alex > > > > > Regards, Parav Pandit -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
