Mike,
Actually, you cannot just assign a /48 to each site. The RIR H-ratio
requirements may make this infeasible. Further, each /48 (/56 for
IANA) allocations must be registered with the RIR, which is an
administrate headache. Finally, there is the issue of reverse lookup
registration for
Pekka,
I do not agree with your statement that If the non-64 prefixes had
not been proscribed, we wouldn't have been able to use the existing
engineering method to develop CGA/SEND specifications. The prefix
length will always be available to the device, either as a
configuration variable or in
Pekka, I also think having that 64bit boundary helped in designing CGAs.
They're more secure when we know IIDs must be 64bit in length.
Pekka Savola wrote:
On Tue, 30 Sep 2008, Brian Dickson wrote:
Dunn, Jeffrey H. wrote:
My basic question is: What basic engineering problem is solved by
Actually, you cannot just assign a /48 to each site. The RIR
H-ratio requirements may make this infeasible. Further, each
/48 (/56 for
IANA) allocations must be registered with the RIR, which is
an administrate headache. Finally, there is the issue of
reverse lookup registration for
In a typical IPv6 ADSL household landscape...
An ADSL IPv6 operational deployment offers a /64 prefix at
home. With that, I can't subnet _and_ use IPv6 stateless
auto-configuration.
In a typical IPv6 ADSL household landscape the ISP will assign
you a /48 with plenty of subnetting space.
[EMAIL PROTECTED] wrote:
In a typical IPv6 ADSL household landscape...
An ADSL IPv6 operational deployment offers a /64 prefix at home.
With that, I can't subnet _and_ use IPv6 stateless
auto-configuration.
In a typical IPv6 ADSL household landscape the ISP will assign you a
/48 with plenty
More to the point, what would a individual household do with Avogadro's
number worth of IPv6 addresses (2^80 = 1.2x10^24)? This seems
extremely wasteful. Further, a reasonable sized ISP with a couple of
million customers would require a /28 or more just for their
residential customer base. This
On Wed, 1 Oct 2008, Alexandru Petrescu wrote:
[EMAIL PROTECTED] wrote:
In a typical IPv6 ADSL household landscape...
An ADSL IPv6 operational deployment offers a /64 prefix at home.
With that, I can't subnet _and_ use IPv6 stateless auto-configuration.
In a typical IPv6 ADSL household
Mohacsi Janos wrote:
On Wed, 1 Oct 2008, Alexandru Petrescu wrote:
[EMAIL PROTECTED] wrote:
In a typical IPv6 ADSL household landscape...
An ADSL IPv6 operational deployment offers a /64 prefix at home.
With that, I can't subnet _and_ use IPv6 stateless auto-configuration.
In a typical
Janos,
You raise an excellent point with respect to using nibble boundaries.
If one uses a partitioning scheme like that in RFC 3531 AND require
that partitions (sets of prefixes) be on nibble boundaries, a /32
allocation with a 64-bit prefix length contains only 8 partitions of 4
bits each.
While the IETF's answer is, effectively, Yes - /48 delegated to a
household the world (or atleast ARIN :)) believes /56's are a more
reasonable size - and I tend to agree.
WRT a reasonable sized ISP with a couple of million customers would require
a /28 or more just for their residential customer
-Original Message- (SNIPPED FOR BREVITY))
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Subject: RE: what problem is solved by proscribing non-64 bit prefixes?
If one uses a partitioning scheme like that in RFC 3531 AND require that
partitions (sets of prefixes) be on
TJ,
I am not sure what point you are trying to make. I never said any bits
were lost, just that longer prefixes make logical address
partitioning easier and more flexible. Am I wrong?
Best Regards,
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.
(301) 448-6965 (mobile)
For what it's worth,
Whenever statelessly auto-configuring an IPv6 address on Ethernet the
10th and 11th bytes are always 'fffe', hardcoded. These are lost bits.
Alex
Dunn, Jeffrey H. wrote:
TJ,
I am not sure what point you are trying to make. I never said any bits
were lost, just that
Alexandru Petrescu wrote:
For what it's worth,
Whenever statelessly auto-configuring an IPv6 address on Ethernet the
10th and 11th bytes are always 'fffe', hardcoded. These are lost bits.
The world has more devices than Ethernet. The Ethernet MAC - EUI-64
trick (thus your lost fffe bits) is
Sorry if I misunderstood, I certainly wasn't trying to put words in your
mouth (or, perhaps, letters on your screen?)
It seemed like you were saying (or atleast implying) some sort of drastic
loss of addressing flexibility due to the desire to break things up on
nibble boundaries. My bad?
On Wed, Oct 01, 2008 at 04:36:57PM +0200, Jeroen Massar wrote:
Alexandru Petrescu wrote:
For what it's worth,
Whenever statelessly auto-configuring an IPv6 address on Ethernet the
10th and 11th bytes are always 'fffe', hardcoded. These are lost bits.
The world has more devices than
Exactly - (IMHO) reserving bits to ensure more widespread compatibility,
future scalability, etc. is not a loss ... in fact, I am glad we have the
bits to (cough) lose in order to accomplish those goals!
/TJ
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Well, Vista uses 'random' host addresses, 64-bit ones. If the spec
had been different way back when, these could equally have been 32 or
48 bits instead. But it wasn't.
That is just one of the several-to-many examples of things that have assume
a 64b IID space.
That is exactly what I mean
Tim Chown wrote:
On Wed, Oct 01, 2008 at 04:36:57PM +0200, Jeroen Massar wrote:
Alexandru Petrescu wrote:
For what it's worth,
Whenever statelessly auto-configuring an IPv6 address on Ethernet the
10th and 11th bytes are always 'fffe', hardcoded. These are lost bits.
The world has more
While some folks will lead us to believe our ability to use up address space is
going to decline, and thus IPv6 appears to be an infinite number to them, there
are those that prefer to simply acknowledge that IPv6 has yet again, a finite
number.
It doesn't hurt to be moderate (not stingy) but
Again, Im not sure why any focus is being put on RIR policy. And at least
within the ARIN RIR what subnet boundary delineates what has to be registered
tends to be a moving target (this is not something we should be referencing).
And as far as registering subnet use, I'm not sure where it
Colleagues,
I am glad to see that my initial humble e-mail has sparked such debate.
Based on discussions with some of my colleagues, I feel the need to
make a few addition points concerning extended addressing. Although I
see no engineering reason why SLAAC will not work with non-64 bit
Dunn, Jeffrey H. wrote:
[...]
As a result of these observations, I am turning the question around:
Why would anyone want to use a 64 bit interface identifier?
I speculate that one possible reason for this was to design a SLAAC over
Ethernet that is reliable, simple, universal and
Could someone confirm the name of the jabber room? My client tells me that
v4v6existence doesn't exist.
Barbara
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Wing
Sent: Tuesday, September 30, 2008 7:49 AM
To: 'Narayanan, Vidya'; 'Mark Townsley';
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).
Sorry - the correct name should be
v4v6coexistence
I just updated the wiki
On Oct 1, 2008, at 9:23 , Stark, Barbara wrote:
Could someone confirm the name of the jabber room? My client tells
me that v4v6existence doesn't exist.
Barbara
-Original Message-
From: [EMAIL PROTECTED]
Couple of additional comments while the v4v6coexistence meeting is on break
:) ...
It doesn't hurt to be moderate (not stingy) but it could hurt to be overly
generous when utilizing addresses. If we can plan our subnet use with
accurate technical aspects and assign according to what is a
Tim,
That sounds more like a call to update the spec than to ignore the
additional functionality available with variable length prefixes.
Best Regards,
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.
(301) 448-6965 (mobile)
-Original Message-
From: [EMAIL PROTECTED]
I speculate that one possible reason for this was to design a SLAAC over
Ethernet that is reliable, simple, universal and straightforward to
implement.
BINGO. And those are all (IMHO) Good Things.
In a way, I see SLAAC to have become so popular as opposed to DHCP.
Were DHCPv6 more developed
TJ wrote:
I speculate that one possible reason for this was to design a SLAAC
over Ethernet that is reliable, simple, universal and
straightforward to implement.
BINGO. And those are all (IMHO) Good Things.
Well yes, they're Good Things.
In a way, I see SLAAC to have become so popular as
TJ wrote:
yet it's hard to extend a common IPv6 subnet
I'm sorry, extend in what fashion? You mean in order to have 2 (or,
n) subnets?
Yes, that, it's hard to add a new unplanned-for-initially Ethernet
subnet to an existing subnet which is allocated a /64 prefix.
or one needs to be
Is there an analogy to IPv4?
The closest fit for those scenarios, off the top of my head, is to add a
layer of NAT. If you were willing to accept the added layer of NAT for
IPv4, is there a reason you wouldn't accept an IPv6 proxy + ULA's behind
it deployment? Failing that, I suppose you could
Alex,
Thank you for providing this opportunity to settle the scope of the
draft which, yes, started these two big threads, the addcon draft.
Our draft does not take a position on the requirements of RFC4291, does
not try to enforce a choice on addressing plans. The draft acknowledges
that in
On Tue, 30 Sep 2008, Alexandru Petrescu wrote:
In a typical WiFi Access Point landscape...
Sellers of these devices don't have a solution to program the WiFi AP
IPv6 in the same way they'd do it for IPv4. For IPv4, the AP receives
an IPv4 address on the wired Ethernet and then does NAT and
Antonio,
So are you suggesting that we replace IPv4 NAT with IPv6 routing proxy?
Best Regards,
Jeffrey Dunn
Info Systems Eng., Lead
MITRE Corporation.
(301) 448-6965 (mobile)
-Original Message-
From: Antonio Querubin [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2008
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Antonio Querubin
Sent: Wednesday, October 01, 2008 3:08 PM
To: Alexandru Petrescu
Cc: Sherman, Kurt T.; IETF IPv6 Mailing List; Ron Bonica;
[EMAIL PROTECTED]; Pasi Eronen; Martin, Cynthia E.;
draft-ietf-
TJ wrote:
further on the wireless interface. For IPv6, although it receives a
huge /64 IPv6 prefix on the wire it can't offer Stateless Autoconfig
on the wireless interface. This begs again for IPv6 NAT.
I'd say it begs for assigning the user a /56 or /48 routed to them on the
/64
On 2008-10-02 02:04, Dunn, Jeffrey H. wrote:
More to the point, what would a individual household do with Avogadro's
number worth of IPv6 addresses (2^80 = 1.2x10^24)? This seems
extremely wasteful. Further, a reasonable sized ISP with a couple of
million customers would require a /28 or
On Wed, 1 Oct 2008, Dunn, Jeffrey H. wrote:
Antonio,
So are you suggesting that we replace IPv4 NAT with IPv6 routing proxy?
I'm suggesting not relying on NAT as a crutch in your specific example.
It seems too easy to just mirror IPv4 practices onto IPv6 and not look at
how IPv6
On Thu, 02 Oct 2008 09:27:37 +1300, Brian E Carpenter
[EMAIL PROTECTED] wrote:
Yes. We shouldn't forget that there are, objectively, 15 trillion
/48s available, so whatever religious faith people may have
in the HD ratio, there *are* plenty of /48s. The value of the
HD ratio (and the RIR
In your previous mail you wrote:
The world has more devices than Ethernet. The Ethernet MAC - EUI-64
trick (thus your lost fffe bits) is just a trick. Take firewire for
example which uses full EUI-64.
= hum, unfortunately Firewire is the bad example: it uses EUI-64 for IDs,
I second Brian's points that:
1. DHCPv6, or more flexible versions of SLAAC, CGA, etc., are needed
2. Basically, in the absence of the ability to subnet arbitrarily (on
non-64 bit boundaries), I'm at the mercy of my upstream.
Further, I would like to summarize the reasons offered on this list
43 matches
Mail list logo
