Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC]

[Victor Kuarsingh <[e-mail]>]

Joel,

[preface - I have a bias]

The basic point being made in [draft-weil-opsawg-provider-address-space] was
that of the options (all problematic in some fashion), the reservation of a
/8 was the most workable option.

I do not think anyone is denying that this option has its problems, but all
options have their problems and we are trying to choose one that is least
impacting.  As noted in the OPSAWG WG session, this (/8 from IANA) was noted
as the option that "poses the least challenges".  This last statement was
made in response to the notion (rightfully so) "protocols like 6to4 would be
impacted".  (by the way there may be a way around this since it's the
example brought up the most)

Of the options posed in draft-azinger-additional-private-ipv4-issues, many
are not workable.  IPv6, although the best solution is just not feasible as
a "complete" solution in the very near future in many networks (now till
past IPv4 run out) since many vendor systems (CPE space, provider space etc)
and upstream applications are just not IPv6 ready now (if anyone does not
like this, please contact your local vendor).  Of the other solutions, the
Class E space is not a realistic option, and address swapping is not likely
to work (I would almost assert - impossible given the fiasco that will arise
after IPv4 run out).

Based on these points, the SP will then be left with a couple of options,
have access to a new /8 to provide more race track while IPv6 is put online
(remember even some transition options need IPv4 space to glue the CPE to
the upstream box like 6RD and NAT444) or camp out on IPv4 space anyway
(unrouted IPv4 space that is assigned.  If the /8 is not provided, then the
latter is likely to occur, which will bring all the problems related to a
the proposed option (in draft-weil) plus the added problems which arise when
camping on other's IP address space.

Victor


On 03/08/10 6:55 PM, "Joel Jaeggli" <[e-mail]> wrote:

> On 8/3/10 2:30 PM, Brian E Carpenter wrote:
>> Philip,
>> 
>> This draft doesn't actually propose to allocate such space, so the fact that
>> some ISPs want it is beside the point of the draft.
>> 
>> There are other drafts that do make such a proposal, but as far as I know
>> they
>> aren't in Last Call.
> 
> I'm sort of mystified by the intersection of
> 
> draft-azinger-additional-private-ipv4-space-issues
> 
> and
> 
> draft-weil-opsawg-provider-address-space-00
> 
> which sites it as an informative reference.
> 
>    Addressing solutions for dealing with the depletion of the IPv4
>    public address space and the lack of available private addresses
>    within large providers are presented in
>    [I-D.azinger-additional-private-ipv4-space-issues] as well as
>    [I-D.shirasaki-nat444-isp-shared-addr].  For larger Service Providers
>    who require more than the 16 million Net-10 addresses, the preferred
>    method for addressing the problems presented in both draft documents
>    is to direct IANA to reserve a /8 from its unassigned IPv4 address
>    pool.
> 
> 
> 
> 
>> Regards
>>    Brian
>> 
>> On 2010-08-03 22:08, Philip Matthews wrote:
>>> Hmm... Perhaps I missing something, but I just re-read the draft and I
>>> didn't see that it was arguing against allocating additional space.   It
>>> pointed out some problems, but they didn't seem unsurmountable to me. The
>>> operators I talked with told me "We know there are problems, but we are
>>> willing to live with them, because we really need extra IPv4 space. We HAVE
>>> to get extra space from somewhere."
>>> Some of the operators I talked with are those behind
>>> http://tools.ietf.org/id/draft-weil-opsawg-provider-address-space-00.txt
>>> - Philip
>>> 
>>> On 2010-08-02, at 19:18 , Brian E Carpenter wrote:
>>> 
>>>> Philip,
>>>> 
>>>> I have no reason to doubt that many ISPs would like a little bit more
>>>> private space. But how does that affect the arguments that any such
>>>> space would create problems, which seems to be the point of this draft?
>>>> 
>>>> Regards
>>>>   Brian
>>>> 
>>>> On 2010-08-03 02:32, Philip Matthews wrote:
>>>>> From my discussions with a number of providers at the IETF meeting last
>>>>> week, they are all looking for a bit more private address space to provide
>>>>> them with a bit of breathing room while they transition to IPv6. Every
>>>>> provider that I talked to was working on IPv6 transition, but none of them
>>>>> could turn it on overnight.
>>>>> - Philip
>>>>> 
>>>>> On 2010-07-26, at 17:31 , Mark Andrews wrote:
>>>>> 
>>>>>> In message 
>>>>>> <AANLkTi=65nxb_baJL=[e-mail]>, Came
>>>>>> ron Byrne writes:
>>>>>>> d.  IPv6-only networks with NAT64 / DNS64.  This option best
>>>>>>> encourages the use of IPv6 and really gets network and application
>>>>>>> designers focused on the end-game, not wallowing in some middle-state
>>>>>>> of CGN / LSN / and endless NAT444.
>>>>>> Anything for big networks will require some form of address sharing
>>>>>> between customers.  NAT64 / DS-LITE / NAT444.
>>>>>> 
>>>>>> -- 
>>>>>> Mark Andrews, ISC
>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>> PHONE: [phone]                 INTERNET: [e-mail]
>>>>>> _______________________________________________
>>>>>> Behave mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/behave
>>>>>> 
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------
>>>>> 
>>>>> _______________________________________________
>>>>> Behave mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/behave
>>> 
>>> 
>> _______________________________________________
>> Behave mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/behave
>> 
> 
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave