Subject: Draft Weil and Draft BDGKS

From: Owen DeLong <[email-masked]>
Date: Tue, 29 Nov 2011 21:07:57 -0800

I strongly support both of these drafts.

Allocation of the /10 will have only minimal negative impacts on the community, if any.

Almost all of the impacts raised in the objections to draft weil will occur whether or not
draft weil is moved to BCP status. The difference is that with draft weil in place, most of
them can actually be mitigated whereas no such mitigation will be possible without
draft weil.

Delaying draft weil is, in this case, roughly equivalent to refusing it because operators
are going to have to start implementing CGN and other IPv4 exhaustion coping
mechanisms whether the IETF is ready or not.

The objections listed in Ron's sending this to IESG ballot are:

- Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network.
- If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft.
- If a special-use /10 is allocated, it will encourage others to request still more special-use address space.
- Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future.

Taking each objection in order:

- Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network.

The first part of this statement is true. The second half is not an entirely accurate
characterization. What this /10 will do is enable carriers and ISPs to provide services
to end users in a consistent manner that vendors can adapt to. Absent this shared
transition space, the uses for this space will not magically disappear and all of the
problems described will still exist. The primary resulting difference will be that it
will consume more global unicast addresses and create more potential for collision
and other negative consequences while simultaneously removing all hope of
allowing vendors to provide mitigation in software.

I am one of the biggest IPv6 cheerleaders in the industry, but, I also have to work
within the framework of operational reality. We're going to run out of IPv4 before
everyone is ready, whether we like it or not. ISPs are going to have to cope with
some various forms of IPv4 services for their customers after exhaustion. No matter
what, this will be a bad situation. Failing to allocate this /10 will make it worse.

- If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft.

I'm not convinced this argument is true, but, it can be made about virtually any RFC
reserving space. Any special use or conventional allocation can be used in a manner
contrary to it's prescribed intent. Rejecting this request with strong support and definite
need from the operational community will not prevent misuse of address space, it will
create the inevitable increase in such misuse as providers are forced to scramble
to the use of "dark space", re-use of global unicast space, and other less than ideal
solutions for this purpose.

- If a special-use /10 is allocated, it will encourage others to request still more special-use address space.

I just don't see this. Nobody made this objection to the Documentation prefixes. Nobody made this
objection to localhost getting a /8. Why is this special use request any more likely to encourage
more such requests than any other?

- Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future.

All of the applications that will break if providers use this space will also break if providers
use any of the following:

	RFC-1918 that collides with the customers internal network.
	Dark space
	Recycled Global Unicast Space
	Class E space

The difference is that with this allocation, providers will all break in the same consistent
way and vendors can mitigate the breakage through software upgrades in some (many)
cases. Without this allocation, providers will use some random mixture of all of the above
in an uncoordinated and undefined way, making it impossible for vendors to provide any
mitigation to such breakage.

Respectfully Submitted,

Owen DeLong
Co-author draft-bdgks
IPv6 Evangelist
Director Professional Services
Hurricane Electric

Member, ARIN Advisory Council

The opinions contained here are my own and do not necessarily reflect the views of my employer, ARIN, or the ARIN Advisory Council.

---

From: [email-masked]
Date: Wed, 30 Nov 2011 12:13:04 -0500

I'd like to thank Owen for explaning his point of view with such clarity 
and I'd like to concur with him by rephrasing in my own words (most of 
this has already been said by others thought). 

Taking the objections in order, again: 

1. Allocation of a special-use /10 does not hasten the deployment of IPv6. 
It only extends the life of the IPv4 network.

Indeed. This affirmation is entirely true IMHO. However the stone-cold 
reality is that IPv6 is not yet ready despite huge multi-years efforts by 
the community and many service providers (speaking by experience here). 
The huge IPv4-only installed base and the lack of IPv6 support by vendors 
can't be ignored wherever the blame is put. 

2. If a special-use /10 is allocated, it will be used as additional RFC 
1918 address space, despite a specific prohibition against such use stated 
by the draft.

Of course. Mark has pointed it out already, we don't need the prohibition 
to be *enforced*, only to have it *written* in the document. If a 
provider's client complains of overlap, then the burden of renumbering is 
on him, not on the ISP or anybody else. 

3. If a special-use /10 is allocated, it will encourage others to request 
still more special-use address space.

I doubt "others", whoever they are, will have 1) sufficient justification 
and 2) time to do so. 

4. Some applications will break. These applications share the 
characteristic of assuming that an interface is globally reachable if it 
is numbered by an non-RFC 1918 address. To date, the only application that 
has been identified as breaking is 6to4, but others may be identified in 
the future.

Applications will break anyway with squat space or multiple overlapping 
RFC1918 space. As Owen and others pointed out, at least with a known 
prefix it can be fixed in a consistent manner. 

CGN will happen and is already happening now because it's the only 
rational way to keep a service provider business running, whether one like 
it or not. Dedicated addressing space will only make this deployment 
cleaner than if it's done with squat space. 

In my very humble opinion, draft Weil is definitely the lesser of to evils 
here. Just as an example, what suspiciously looks like squat space can be 
seen now (*>i47.154.0.0/16 ... 3561 701 9929 4808 4808 i). At least with a 
dedicated prefix it can be properly filtered and blackholed. 

These were my 2 (Canadian) cents.

JF Tremblay
Long time IPv6 enthusiast and Sr IPv6 Engineer at Videotron

(The opinions contained here are my own and do not necessarily reflect the 
views of my $employer or any other affiliation)

Allocation of the /10 will have only minimal negative impacts on the 
community, if any.

Almost all of the impacts raised in the objections to draft weil will 
occur whether or not
draft weil is moved to BCP status. The difference is that with draft weil 
in place, most of
them can actually be mitigated whereas no such mitigation will be possible 
without
draft weil.

Delaying draft weil is, in this case, roughly equivalent to refusing it 
because operators
are going to have to start implementing CGN and other IPv4 exhaustion 
coping
mechanisms whether the IETF is ready or not.

- Allocation of a special-use /10 does not hasten the deployment of IPv6. 
It only extends the life of the IPv4 network.
- If a special-use /10 is allocated, it will be used as additional RFC 
1918 address space, despite a specific prohibition against such use stated 
by the draft.
- If a special-use /10 is allocated, it will encourage others to request 
still more special-use address space.
- Some applications will break. These applications share the 
characteristic of assuming that an interface is globally reachable if it 
is numbered by an non-RFC 1918 address. To date, the only application that 
has been identified as breaking is 6to4, but others may be identified in 
the future.

- Allocation of a special-use /10 does not hasten the deployment of IPv6. 
It only extends the life of the IPv4 network.

The first part of this statement is true. The second half is not an 
entirely accurate
characterization. What this /10 will do is enable carriers and ISPs to 
provide services
to end users in a consistent manner that vendors can adapt to. Absent this 
shared
transition space, the uses for this space will not magically disappear and 
all of the
problems described will still exist. The primary resulting difference will 
be that it
will consume more global unicast addresses and create more potential for 
collision
and other negative consequences while simultaneously removing all hope of
allowing vendors to provide mitigation in software.

I am one of the biggest IPv6 cheerleaders in the industry, but, I also 
have to work
within the framework of operational reality. We're going to run out of 
IPv4 before
everyone is ready, whether we like it or not. ISPs are going to have to 
cope with
some various forms of IPv4 services for their customers after exhaustion. 
No matter
what, this will be a bad situation. Failing to allocate this /10 will make 
it worse.

- If a special-use /10 is allocated, it will be used as additional RFC 
1918 address space, despite a specific prohibition against such use stated 
by the draft.

I'm not convinced this argument is true, but, it can be made about 
virtually any RFC
reserving space. Any special use or conventional allocation can be used in 
a manner
contrary to it's prescribed intent. Rejecting this request with strong 
support and definite
need from the operational community will not prevent misuse of address 
space, it will
create the inevitable increase in such misuse as providers are forced to 
scramble
to the use of "dark space", re-use of global unicast space, and other less 
than ideal
solutions for this purpose.

- If a special-use /10 is allocated, it will encourage others to request 
still more special-use address space.

I just don't see this. Nobody made this objection to the Documentation 
prefixes. Nobody made this
objection to localhost getting a /8. Why is this special use request any 
more likely to encourage
more such requests than any other?

- Some applications will break. These applications share the 
characteristic of assuming that an interface is globally reachable if it 
is numbered by an non-RFC 1918 address. To date, the only application that 
has been identified as breaking is 6to4, but others may be identified in 
the future.

All of the applications that will break if providers use this space will 
also break if providers
use any of the following:

                 RFC-1918 that collides with the customers internal 
network.
                 Dark space
                 Recycled Global Unicast Space
                 Class E space

The difference is that with this allocation, providers will all break in 
the same consistent
way and vendors can mitigate the breakage through software upgrades in 
some (many)
cases. Without this allocation, providers will use some random mixture of 
all of the above
in an uncoordinated and undefined way, making it impossible for vendors to 
provide any
mitigation to such breakage.

Respectfully Submitted,

Owen DeLong
Co-author draft-bdgks
IPv6 Evangelist

The opinions contained here are my own and do not necessarily reflect the 
views of my employer, ARIN, or the ARIN Advisory Council.

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Daryl Tanner <[email-masked]>
Date: Wed, 30 Nov 2011 21:00:42 +0000

I echo Owen and JF's comments

Given the available options, the dedicated /10 provides the least
problematic solution.

If the address space used by CGN is standardised, and identifiable then it
can be managed appropriately by everyone in a consistent way.

The sooner this is adopted, the easier it becomes to manage.

Daryl

On 30 November 2011 17:13, <[email-masked]> wrote:

> and I'd like to concur with him by rephrasing in my own words (most of this
> has already been said by others thought).
>
> the community and many service providers (speaking by experience here). The
> huge IPv4-only installed base and the lack of IPv6 support by vendors can't
> be ignored wherever the blame is put.
>
> characteristic of assuming that an interface is globally reachable if it is
> numbered by an non-RFC 1918 address. To date, the only application that has
> been identified as breaking is 6to4, but others may be identified in the
> future.
>
> RFC1918 space. As Owen and others pointed out, at least with a known prefix
> it can be fixed in a consistent manner.
>
> characteristic of assuming that an interface is globally reachable if it is
> numbered by an non-RFC 1918 address. To date, the only application that has
> been identified as breaking is 6to4, but others may be identified in the
> future.
>
> characteristic of assuming that an interface is globally reachable if it is
> numbered by an non-RFC 1918 address. To date, the only application that has
> been identified as breaking is 6to4, but others may be identified in the
> future.
>