Subject: deriving MAC address from destination Link local address without Neighbor discovery

From: Parav Pandit <[email-masked]>
Date: Wed, 14 Apr 2010 22:55:53 -0700 (PDT)

Hi,

As per RFC 2464, Link local address for Ethernet based interfaces are based on the EUI-64 (derived from the MAC address).

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).

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.

2. Does it mean that in Ethernet networks, interface can have only one Link-local address? If not then we violate the RFC 2464.

3. Does RFC 4941 Privacy extension for autoconf apply to Ethernet interfaces?

Regards,
Parav Pandit

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Apr 2010 23:40:21 -0700

There has been some water that passed under that bridge. They not only come from MAC addresses, but from random number generators and cryptographic algorithms - and can simply be numbers assigned by administrators.

In addition to

2464 Transmission of IPv6 Packets over Ethernet Networks. M. Crawford.
     December 1998. (Format: TXT=12725 bytes) (Obsoletes RFC1972) (Status:
     PROPOSED STANDARD)

take a look at

http://www.ietf.org/rfc/rfc3315.txt
3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms,
     Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003.
     (Format: TXT=231402 bytes) (Updated by RFC4361, RFC5494) (Status:
     PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc3972.txt
3972 Cryptographically Generated Addresses (CGA). T. Aura. March 2005.
     (Format: TXT=51473 bytes) (Updated by RFC4581, RFC4982) (Status:
     PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc4291.txt
4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering.
     February 2006. (Format: TXT=52897 bytes) (Obsoletes RFC3513) (Status:
     DRAFT STANDARD)

http://www.ietf.org/rfc/rfc4862.txt
4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten,
     T. Jinmei. September 2007. (Format: TXT=72482 bytes) (Obsoletes
     RFC2462) (Status: DRAFT STANDARD)

http://www.ietf.org/rfc/rfc4941.txt
4941 Privacy Extensions for Stateless Address Autoconfiguration in
     IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format:
     TXT=56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD)

On Apr 14, 2010, at 10:55 PM, Parav Pandit wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

http://www.ipinc.net/IPv4.GIF

---

From: Parav Pandit <[email-masked]>
Date: Thu, 15 Apr 2010 00:23:44 -0700 (PDT)

Hi Fred,

In your reply,
> They not only come from MAC addresses, but from random number 
> generators...

I didn't understand "They" apply to 64-bit of link_local address or 
64-bit of autoconf/dhcp address or both?

What I understood is: 
RFC 3972 contradicts with RFC 2464.

Or both the methods are correct for ETHERNET for Link-local and autoconf addresses?

RFC 4291 asks to refer the Link layer specific RFC for the 64-bit Interface Id of the link-local address - which is 2464 (for Ethernet).

So thats the confusion I have.

Or 
the RFC 3972 doesn't apply to the 64-bits of the Link-local addresses, but it applies to 64-bit of the addresses configured via DHCPv6
and/or stateless auto-conf RFCs 3315, 4862?

Regards,
Parav Pandit

--- On Thu, 4/15/10, Fred Baker <[email-masked]> wrote:

> From: Fred Baker <[email-masked]>
> Subject: Re: deriving MAC address from destination Link local address without Neighbor discovery
> To: "Parav Pandit" <[email-masked]>
> Cc: [email-masked]
> Date: Thursday, April 15, 2010, 12:10 PM
> There has been some water that passed
> under that bridge. They not only come from MAC addresses,
> but from random number generators and cryptographic
> algorithms - and can simply be numbers assigned by
> administrators.
> 
> In addition to
> 
> > As per RFC 2464, Link local address for Ethernet based
> interfaces are based on the EUI-64 (derived from the MAC
> address).
> > 
> > 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).
> > 
> > 2. Does it mean that in Ethernet networks, interface
> can have only one Link-local address? If not then we violate
> the RFC 2464.
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Apr 2010 11:31:18 +0200

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.

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?

> 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?

> 3. Does RFC 4941 Privacy extension for autoconf apply to Ethernet

Well yes I believe so, I suppose I have it running on my PC right now.

Alex

> Regards, Parav Pandit
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Parav Pandit <[email-masked]>
Date: Thu, 15 Apr 2010 02:53:10 -0700 (PDT)

Inline.

Parav

--- On Thu, 4/15/10, Alexandru Petrescu <[email-masked]> wrote:

> From: Alexandru Petrescu <[email-masked]>
> Cc: "Ipv" <[email-masked]>
> Date: Thursday, April 15, 2010, 3:01 PM
> interfaces
[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.

> Why do you need to do this message-less reverse
[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.

> can have only

[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?
> 
[Parav] May be because they follow desolate RFC 1972.

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 15 Apr 2010 06:17:56 -0700

> netbooks) are potentially very numerous one may think it could be as

Just as a point of clarification, 3G devices do not use PPP generally.

The process is described in RFC 3316  Appendix A

Cameron

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Apr 2010 15:54:22 +0200

> Just as a point of clarification, 3G devices do not use PPP generally.

Sorry what do they use to assign an IP address to the end node?

I could have said GPRS instead.

I could have said that I used ppp myself to set up a link which is 
qualified as 3G by the operator.

Alex

---

From: Fred Baker <[email-masked]>
Date: Thu, 15 Apr 2010 08:05:26 -0700

I would say that perhaps RFC 3972 updates 2464. As I perceive this, SLAAC is how one vets an address, and addresses include an EID that can come from one of several sources.

On Apr 15, 2010, at 12:23 AM, Parav Pandit wrote:

>> to Ethernet interfaces?

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 15 Apr 2010 20:16:58 -0400

Hi Parav,
   Please see comments inline.

> Correct me if my understanding is incorrect.

Address resolution is required even for link-local addresses. Link-local 
addresses can be formed with arbitrary IIDs that do not need to be 
derived from MAC addresses and more importantly <the IIDs carry no 
indication whether they were formed from MAC addresses or not>.

> 2. Does it mean that in Ethernet networks, interface can have only one Link-local address? If not then we violate the RFC 2464.

RFC2464 does not have any normative language in this regard. Why do you 
think this will violate RFC2464?

> 3. Does RFC 4941 Privacy extension for autoconf apply to Ethernet interfaces?

Yes. Certainly.

Thanks
Suresh

---

From: Parav Pandit <[email-masked]>
Date: Fri, 16 Apr 2010 11:01:39 -0700 (PDT)

Please fine inline response.
Parav

--- On Fri, 4/16/10, Suresh Krishnan <[email-masked]> wrote:

> From: Suresh Krishnan <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Date: Friday, April 16, 2010, 5:46 AM
> Hi Parav,
> > 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).
> > 
> Address resolution is required even for link-local
> addresses. Link-local addresses can be formed with arbitrary
> IIDs that do not need to be derived from MAC addresses and
> more importantly <the IIDs carry no indication whether
> they were formed from MAC addresses or not>.
> 
> > 
> RFC2464 does not have any normative language in this
> regard. Why do you think this will violate RFC2464?
> 
[Parav] RFC 2464 says, it can fall back to other mechanism of assigning it by administrator when ND fails (other system owns it).
Its silent about the "not using" other mechanism.
So I thought EUI-64 is the only way to assign link-local address.
Thanks for the clarifications.