On 11/29/2011 15:04, Mark Andrews wrote:
> In message <4ed55726.5090...@dougbarton.us>, Doug Barton writes:
>> On 11/29/2011 13:59, Chris Donley wrote:
>>> And that's one of the reasons this draft updates 5735. If routers make
>>> decisions as to whether or not to enable a feature based on whether
>>> behind a public or private address, having a defined address range for
>>> CGN space will be significantly easier to deal with than to have
>>> arbitrary address ranges selected on a per-ISP basis.
>>
>> But that's certainly not the only way to handle that problem, right? If
>> the router needs to be updated to recognize the new space anyway,
>> wouldn't it make more sense to update it with a more generic mechanism
>> to signal "You're behind a private address?" That way you can use the
>> same mechanism for IPv4 and IPv6.
> 
> It doesn't have to be one or the other. 

Of course it doesn't have to be, it *should* be.

> It can be both.  Having address
> space that the CPE can identify as non-public without the ISP having
> to configure something is a a good thing.

How are the CPEs going to recognize the new space without something
being configured? They will need a software upgrade, right? So why is a
generic, boolean flag not a better idea than allocating a magic block?

> As much as I would like to see IPv6 native everywhere as soon as
> possible forcing each ISP to choose part of their allocated address
> space or to use RFC 1918 address space behind CGN's is not good
> resource management.

I don't see anything wrong with using 1918 space for this purpose.

> RFC 1918 space is suppose to be used *within* a enterprise.  Using
> it to *connect* enterprises is out of bounds. 

How are you defining enterprise in this context?


Doug

-- 

                "We could put the whole Internet into a book."
                "Too practical."

        Breadth of IT experience, and depth of knowledge in the DNS.
        Yours for the right price.  :)  http://SupersetSolutions.com/

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to