Hi Alistair and Skeeve,
Further to my last email, I do not see the connection between RFC 4291's feature around EUI-64 and how it would be mandating use of /64 assignments for end-customers ?
The EUI-64 is just one of the features in RFC 4291 that a user can leverage to automatically have the remaining portion of their Interface address assigned using e.g. Ethernet interface's MAC address. It however by no means poses any requirement in IPv6 address assignments that this MUST be done(?).
regards
Usman
From: Usman Latif <osmankh@yahoo.com>
To: Skeeve Stevens <Skeeve@eintellego.net>; "sig-policy@lists.apnic.net" <sig-policy@lists.apnic.net>
Sent: Friday, 16 September 2011 9:02 PM
Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
So it seems that a previous RFC (regarding stateless autoconfig) is driving us to use /64s for edge-assignments? - this to me seems more like a constrain than a reason.
I just hope that we don't look back at this time in future and regret taking this
decision because it seems that we are starting out very very liberally in our address assignment approach (potentially wasting a lot of space) and could potentially come to a similar exhaustion problem far earlier than if we had started out more conservatively with /96s or something similar.
In all honesty, I am not convinced that we have the proper justification or a reason to suggest using /64s for edge-assignments on day-zero of IPv6 rollout in the
world.
regards
Usman
From: Skeeve Stevens <Skeeve@eintellego.net>
To: Skeeve Stevens <Skeeve@eintellego.net>; Usman Latif <osmankh@yahoo.com>; "sig-policy@lists.apnic.net" <sig-policy@lists.apnic.net>
Sent: Friday, 16 September 2011 8:47 PM
Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
I seem to have just repeated most of what AJ just said.
...Skeeve
--
Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists
skeeve@eintellego.net ; www.eintellego.net
Phone: 1300 753 383 ; Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 ; skype://skeeve
facebook.com/eintellego or eintellego@facebook.com
twitter.com/networkceoau ; www.linkedin.com/in/skeeve
PO Box 7726, Baulkham Hills, NSW 1755 Australia
--
eintellego - The Experts that the Experts call
- Juniper - HP Networking - Cisco - Brocade - Huawei
Hey Usman,
As you were just at the AUSNOG conference, if you posted on the AUSNOG list you may get the opinions from those at the conference you attended – and why they are choosing to do it that way.
I think the primary driver of /64 is to support EUI64, and as such most are going longer – to a 56, or perhaps a 48 to allow for multiple networks at the same site… although it does feel like an awful lot of space, it seems reasonable given the availability
of the space and the preference to allow SLAAC to function.
...Skeeve
--
Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists
Phone: 1300 753 383 ; Fax: (+612) 8572 9954
twitter.com/networkceoau ; www.linkedin.com/in/skeeve
PO Box 7726, Baulkham Hills, NSW 1755 Australia
--
eintellego - The Experts that the Experts call
- Juniper - HP Networking - Cisco - Brocade - Huawei
Hi Skeeve,
Could you please relay my query to the APNIC-TALK list ? I dont have the email address for them.
I am willing to participate on any current forum which discusses the address assignment recommendations.
In my opinion, stateless autoconfiguration is little justification (to start assigning /64s for end-customers) when it comes to the issue of address exhaustion which was the main driver to come up with a 128 bit address space. If we start assigning /64s to
end-customers right from day-zero, we are effectively halving the whole 128 bit address space and making all the vital /64s unavailable for use in future.
We can always ask vendors to modify the stateless autoconfiguration algorithm and look into slightly more conservative addressing scheme.
And we all know how difficult it is to reclaim address spaces from customers once they have deployed them.
We are talking about assigning 2^64 addresses to potentially small-scale customers ?? I don't understand the justification there.
Randy Bush: Yes I have read RFC 6177 and I am mainly concerned about its recommendations of assigning /64s - some ISPs in Australia are now taking these recommendations and assigning even residential edge customers with a /64 IPv6 space (I found
this out after participating in AUS-NOG conference and was alarmed by this).
I can be reached on the following:
Usman Latif
Senior Network Engineer
Uecomm (Singtel-Optus Limited)
Phone: +61 2 8085 3212
Sydney, Australia
regards
Usman Latif
From: Skeeve Stevens <
Skeeve@eintellego.net>
To: Usman Latif <
osmankh@yahoo.com>; "
sig-policy@lists.apnic.net" <
sig-policy@lists.apnic.net>
Sent: Friday, 16 September 2011 6:49 PM
Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
Hi Usman,
This is a good question and worth discussing. But, it should be discussed in perhaps the apnic-talk list, not the sig-policy list, which is for policy related discussion.
Let's take it over there, and let the discussion begin!
…Skeeve
APNIC Sig-Policy Co-Chair
--
Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists
Phone: 1300 753 383 ; Fax: (+612) 8572 9954
twitter.com/networkceoau ; www.linkedin.com/in/skeeve
PO Box 7726, Baulkham Hills, NSW 1755 Australia
--
eintellego - The Experts that the Experts call
- Juniper - HP Networking - Cisco - Brocade - Huawei
Hi,
I am trying to understand the reasoning and logic behind IETF/IANA's decision to recommend assignments of /64 addresses to residential CPEs ??
In my opinion, this would result in a lot of unnecessary wastage of IPv6 address space.
Can someone help me to point towards the drivers behind this thinking?
IMO a /96 IPv6 assignment to residential customers is more than enough.
regards
Usman
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy
* sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy