Re: Why would anyone want to use a 64 bit interface identifier?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why would anyone want to use a 64 bit interface identifier?
- To: "Dunn, Jeffrey H." <jdunn at mitre.org>
- Subject: Re: Why would anyone want to use a 64 bit interface identifier?
- From: Jeroen Massar <jeroen at unfix.org>
- Date: Wed, 01 Oct 2008 17:35:53 +0200
- Cc: Alexandru Petrescu <alexandru.petrescu at gmail.com>, IETF IPv6 Mailing List <ipv6 at ietf.org>, Pekka Savola <pekkas at netcore.fi>, Ron Bonica <rbonica at juniper.net>, Steve_Eiserman at ao.uscourts.gov, Pasi Eronen <Pasi.Eronen at nokia.com>, "Sherman, Kurt T." <ksherman at mitre.org>, Brian E Carpenter <brian.e.carpenter at gmail.com>, draft-ietf-v6ops-addcon at tools.ietf.org, ralph.liguori at disa.mil, night at nist.gov, dougm at nist.gov, V6ops Chairs <v6ops-chairs at tools.ietf.org>, "Martin, Cynthia E." <cemartin at mitre.org>
- Delivered-to: ietfarch-ipv6-web-archive at core3.amsl.com
- Delivered-to: ipv6 at core3.amsl.com
- In-reply-to: <0AC4B700F00DBB4C94F95727E0991414014B24F7 at IMCSRV7.MITRE.ORG>
- List-archive: <https://www.ietf.org/mailman/private/ipv6>
- List-help: <mailto:ipv6-request@ietf.org?subject=help>
- List-id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
- List-post: <mailto:ipv6@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
- Openpgp: id=333E7C23
- Organization: Unfix
- References: <48DB374B.1000308 at piuha.net> <0AC4B700F00DBB4C94F95727E0991414014B2441 at IMCSRV7.MITRE.ORG> <48E230D5.3040204 at gmail.com> <0AC4B700F00DBB4C94F95727E0991414014B24D2 at IMCSRV7.MITRE.ORG> <48E24F78.70004 at ca.afilias.info> <alpine.LRH.2.00.0809301958310.20045 at netcore.fi><48E27D57.7040807 at ca.afilias.info> <48E28ABD.1050602 at gmail.com> <48E2977E.5040209 at ca.afilias.info> <0AC4B700F00DBB4C94F95727E0991414014B24F4 at IMCSRV7.MITRE.ORG> <48E376EB.9060401 at gmail.com> <0AC4B700F00DBB4C94F95727E0991414014B24F7 at IMCSRV7.MITRE.ORG>
- Sender: ipv6-bounces at ietf.org
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080914 Lightning/0.9 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666
Dunn, Jeffrey H. wrote:
> Alex,
>
> While I agree that the use of an EUI-64 network identifier predicates a
> 64-bit prefix, I am not convinced that an EUI-64 is the best way to go.
> After all, the Ethernet MAC address is only 48 bits, so we are
> essentially "throwing away" 16 bits (assuming that the identifier is
> globally unique). Further, we require the use of DAD, so why not just
> use a 32 bit pseudo random number generated by the device and let DAD
> take care of the possibility of address duplication?
Because in EUI-64 there should not be any clashes. (you know, like MAC
addresses they never run out ;)
What you also seem to be forgetting is this thing called
'statelessness'. And that you might want to IPv6-enable your carpet.
Also, at 2 DAD clashes most stacks stop trying and give up, tada your
whole carpet is now inaccessible...
(Might I nastily suggest that people start reading up on the history on
certain choices in the IPv6 architecture? Christian Huitema's IPv6* book
is really interesting and so is IPng* by Bradner and Mankin for even
older history).
Greets,
Jeroen
* = http://www.amazon.com/IPv6-New-Internet-Protocol-2nd/dp/0138505055
http://www.amazon.com/IPNG-Internet-Protocol-Next-Generation/dp/B000OOKP2A
(just picking Amazon as it was the first hit in google, nothing else...)
Attachment:
signature.asc
Description: OpenPGP digital signature
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.