(no subject)

"Anjali Gajendragadkar" <anjali1004@gmail.com> Tue, 18 September 2007 05:08 UTC

Return-path: <ipv6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXVJe-0000I1-R9; Tue, 18 Sep 2007 01:08:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXVJc-0000Eq-QR for ipv6@ietf.org; Tue, 18 Sep 2007 01:08:04 -0400
Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXVJS-0004SX-Ml for ipv6@ietf.org; Tue, 18 Sep 2007 01:08:00 -0400
Received: by py-out-1112.google.com with SMTP id d32so6259472pye for <ipv6@ietf.org>; Mon, 17 Sep 2007 22:07:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=+JAHBFnyJHDph8mKL2KADqQiFgrXS4KPo2DkSbeTdL8=; b=LLm8eGOh0SSJSOkf9dU7E6qU3eZ6gNXu6NIR9te3VcITl4+3nHJ5eaCJgeX+mXNVDoOZ5AncSvRJI8zCRgB+j8EGUFnnXAqOtgEq+LnPtaHrL3mgGC9Fn3gpa5MhhIaW7iUeHwpHBe9oeVxZMpmYnfzkUUUBzcnq+y/S4Z6M8w0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=YOV3I0FRvUrVwND7LaY4PRLaHGjifg1rxIyKE01LTvBrcxdRTYbO0osnuxzjVkgc8Ri6exEOVt4P/lMSUH6NEG2a21vk3s6W+ttWyGt2vdk1YNUpcmwXy+/VjOXht8kYaIyinEj9p55RQqyXjGeky55KsyEeo+QJz6CoW6ZcwQQ=
Received: by 10.65.224.11 with SMTP id b11mr12124408qbr.1190092034988; Mon, 17 Sep 2007 22:07:14 -0700 (PDT)
Received: by 10.65.81.5 with HTTP; Mon, 17 Sep 2007 22:07:14 -0700 (PDT)
Message-ID: <79d3f7750709172207j75027d83q4b086a47f9872bc4@mail.gmail.com>
Date: Tue, 18 Sep 2007 10:37:14 +0530
From: Anjali Gajendragadkar <anjali1004@gmail.com>
To: ipv6@ietf.org
MIME-Version: 1.0
X-Spam-Score: 4.8 (++++)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Subject: (no subject)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2058266293=="
Errors-To: ipv6-bounces@ietf.org

Conime,
> who says 64 is? Long story there that I wasn't a party to.

That was actually decided during the review of the SIPP proposal, and was p=
retty much a condition for selecting SIPP (and 128 bits) as IPv6.

> But OK, it
> became 128 bits, and someone started talking about maybe using the
> MAC address in the host part.

Part of same review. SIPP was competing for selection with TUBA, a proposal=
 based on CLNP. CLNP (i.e. the OSI datagram layer) used variable length add=
resses, but the most prominent form featured 20 bytes addresses whose last =
48 bits where derived from the 48 bit Ethernet address of the host. That al=
lowed for auto-configuration, much like IPX. Auto-configuration based on MA=
C address was pretty much part of the initial deal, the rationale for movin=
g from 64 to 128 bit. "Someone" was really many people, but if I had to pic=
k a name I would say Scott Bradner.

> Someone noted that not all MAC
> addresses were 48 bits; for example, an E.164 address (a telephone
> number by any other name) when represented as BCD digits might easily
> be 16 digits, and some 802 series addresses are 64 bits. So it was
> suggested that 64 bits be set aside for the host part.

That was, and still is, the official IEEE line. IEEE 802 is very concerned =
that 48 bit is not quite enough.

-- Christian Huitema



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------