(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 --------------------------------------------------------------------
- Re: (no subject) Tim Osburn
- (no subject) FIGEN CETIN
- (no subject) B.Svante Eriksson
- (no subject) masuda yuko
- (no subject) masuda yuko
- (no subject) timbeck04
- RE: (no subject) Christian Huitema
- (no subject) timbeck04
- RE: Are privacy extensions, RFC 3041, defined for… John Spence
- RE: Are privacy extensions, RFC 3041,defined for … timothy enos
- (no subject) judith minkin
- (no subject) Anjali Gajendragadkar
- (no subject) Ignatios Souvatzis
- Re: What's 16 bits between friends? Brian Dickson
- Re: What's 16 bits between friends? Ignatios Souvatzis
- RE: What's 16 bits between friends? michael.dillon
- Re: What's 16 bits between friends? Brian Dickson
- Re: What's 16 bits between friends? Brian Dickson
- Re: What's 16 bits between friends? Mark Smith
- RE: What's 16 bits between friends? michael.dillon
- RE: What's 16 bits between friends? Templin, Fred L