Subject: Re: IPv6 is being deployed !

From: [email-masked] (Noel Chiappa)
Date: Fri, 5 Nov 2004 19:30:59 -0500 (EST)

> From: JORDI PALET MARTINEZ <[email-masked]>

    > Will all the respect, this is ridiculous.
    > You are out of the market, I feel.

To the contrary, I am using data from live IPv6 BGP routing tables, available
here:

    http://bgp.potaroo.net/index-v6.html

I always prefer real data to marketing hype.

	Noel

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

---

From: Tim Chown <[email-masked]>
Date: Sat, 6 Nov 2004 01:03:59 +0000

> I always prefer real data to marketing hype.

Well, it looks like nice linear growth :)

I'd be interested for some numbers on how big the v6 BGP routing table
would get relative to the existing v4 one, which is at, what, 150k entries?

The current 600 isn't a lot, but if you take the case (close to me) of the
UK academic network, in v6 we have one prefix (2001:630::/32), while in
v4 there's pretty much one per university, so 200-300+ entries, since the
universities got IP pre-CIDR.

If that were typical across all ISPs, then you're at your 150k equivalent
already.   Seems unlikely though. 

In v6 there will also be no PI blocks advertised (unless some big corps 
have blagged /32's).

Which major ISPs do not yet have v6 address space?

Which of those have enough address space? (i.e. /20-something rather than /32?)

tim

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 06 Nov 2004 02:17:17 +0100

Hi Noel,

Then you should not just look for data, but compare it. For instance, when
IPv4 was initially deployed, how much time took to get some "realistic"
deployment.

Also remember that in IPv6 only /32 are announced, so you can't just compare
it one to one.

Regards,
Jordi

> De: [email-masked] (Noel Chiappa)
> Responder a: [email-masked]
> Fecha: Fri,  5 Nov 2004 19:30:59 -0500 (EST)
> Para: [email-masked]
> CC: [email-masked]
> Asunto: Re: IPv6 is being deployed !
> 

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Bill Manning <[email-masked]>
Date: Fri, 5 Nov 2004 17:54:00 -0800

> Also remember that in IPv6 only /32 are announced, so you can't just 

	now jordi, the party line is nice, but it is clear that the mantra 
"only /32s" is
	false on inspection and has -NEVER- been true throughout most peering.
	granted, you may enforce that at -YOUR- boundary, but don't presume
	that to reflect reality.   there are at least six prefixes who have a 
minimum
	injection of a /48 for the "global"  Internet and untold numbers of 
others
	inside walled-gardens.

--bill

---

From: Joe Abley <[email-masked]>
Date: Fri, 5 Nov 2004 22:46:09 -0500

> Also remember that in IPv6 only /32 are announced, so you can't just 

Apologies for the injection of operational content, but if anybody here 
is only accepting /32s on their v6 borders, their import policies are 
broken. There are legitimate prefixes being announced which are both 
shorter and longer than 32 bits (several high-profile nameservers fit 
into the latter category).

http://www.space.net/~gert/RIPE/ipv6-filters.html

Joe

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 06 Nov 2004 18:03:09 -0500

Hi Bill,

Well, but not everybody is doing that, some people is only accepting /32
(also /35 because the older policy) and of course, anything bigger (we have
already one /20).

What that means is that just looking at BGP on v6 and comparing to v4, is
not fair, and not provide the right picture.

Regards,
Jordi

> De: Bill Manning <[email-masked]>
> Fecha: Fri, 5 Nov 2004 17:54:00 -0800
> Para: [email-masked]
> CC: [email-masked]
> Asunto: IPv6 -HAS- been deployed -- yawn.
> 
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Nov 2004 11:24:16 +0100

> Apologies for the injection of operational content,

You've been on NANOG too long.  :-)

> but if anybody here is only accepting /32s on their v6 borders, their 
> import policies are broken.

What's broken is that they believe the IANA and RIRs when they say:

4.3.  Minimum Allocation

    RIRs will apply a minimum size for IPv6 allocations, to facilitate
    prefix-based filtering.

    The minimum allocation size for IPv6 address space is /32.

http://www.iana.org/ipaddress/ipv6-allocation-policy-26jun02

(See http://www.bgpexpert.com/archive2003q4.php for the full rant.)

> There are legitimate prefixes being announced which are both shorter 
> and longer than 32 bits (several high-profile nameservers fit into the 
> latter category).

That's inconsistent with the published policy. Either reality or the 
policy documents have to be changed. When is the I* community going to 
deploy some quality control???

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 8 Nov 2004 07:28:48 -0500

On Mon, Nov 08, 2004 at 11:24:16AM +0100,
 Iljitsch van Beijnum <[email-masked]> wrote 

> What's broken is that they believe the IANA and RIRs when they say:

The IANA may say so but not all the RIRs do:

http://www.arin.net/policy/index.html#six10

> That's inconsistent with the published policy. 

No. See above.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Nov 2004 13:57:01 +0100

> http://www.arin.net/policy/index.html#six10

You mean:

"6.10.   Micro-allocation

  ARIN will make micro-allocations to critical infrastructure providers 
of the Internet, including public exchange points, core DNS service 
providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as 
well as the RIRs and IANA. These allocations will be no longer than a 
/24 using IPv4 or a /48 using IPv6."

So I guess there was _some_ progress the past 10 months. However, they 
still also say:

"6.4.3.     Minimum Allocation

The minimum allocation size for IPv6 address space is /32."

So the problem is still there. (Same text is also still present at IANA 
and the other RIRs.)

> No. See above.

When there is an inconsistency, you can't fix it by adding more data. 
You need to remove/change something. The fact that the information 
necessary to do route filtering is present in 5 locations and policies 
are created in 4 places doesn't help.

---

From: Bill Manning <[email-masked]>
Date: Mon, 8 Nov 2004 08:28:16 -0500

> So the problem is still there. (Same text is also still present at 
> IANA and the other RIRs.)

	the "problem" is that folks seem to have a different take on the word 
FACILITATE
	in the above section.  facilitate != mandate....  e.g. one could 
expect that delegations
	made from the RIRs -when this policy was/is in force- to be on /32 
alignments.
	for delegations made under different regimes, the delegation sizes may 
be different...
	like the /35s that were popular from the RIR community before the /32 
agreement was
	reached.  Or the /48s  that predated the /35s...
> are created in 4 places doesn't help.
	it is important to remember that neither the IETF nor the RIR can 
manage/conserve the entries in anyones routing/forwarding tables.
	The IETF (imho) should confine itself to protocol work,  The RIRs 
should confine themselves to being wise stewards of the addressing
	resources, and the ISPs need to worry about the operational 
coordination of routing...  such is not the perview of either the IETF, 
the IANA task,
	or the RIRs.   ....

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 8 Nov 2004 08:39:44 -0500

On Mon, Nov 08, 2004 at 01:57:01PM +0100,
 Iljitsch van Beijnum <[email-masked]> wrote 

> "6.10.   Micro-allocation

Yes, the one used by Verisign's a.gtld-servers.net and
b.gtld-servers.net (see ARIN's whois).
 
> The fact that the information necessary to do route filtering is
> present in 5 locations and policies are created in 4 places doesn't
> help.

No, in one location :-)

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 8 Nov 2004 19:31:57 +0100

On 2004-11-08, at 14.28, Bill Manning wrote:

>> necessary to do route filtering is present in 5 locations and 
>> policies are created in 4 places doesn't help.
>>
> coordination of routing...  such is not the perview of either the 
> IETF, the IANA task,
> 	or the RIRs.   ....

Well, the RIRs will actually hand out address-space explicitly saying 
they make no guarantees for routability. If you apply for IPv4 PI space 
and can only justify the equivalence of a /26 you will get a /26.

- - kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Nov 2004 21:58:50 +0100

> FACILITATE in the above section.

If you mean that the RIRs don't tell people they must or even should 
filter, that's of course true. Quite the opposite: RIRs are very 
reluctant to tell people what to do (except jump through enormous 
amounts of administrative hoops, of course).

However, I take the text I quoted to mean "it's ok to reject all 
prefixes longer than 32 bits". And I don't see how any other meaning 
could make sense.

> facilitate != mandate....  e.g. one could expect that delegations 

Yes. Which the microallocations aren't.

> be different...	like the /35s that were popular from the RIR community 
> before the /32 agreement was reached.  Or the /48s  that predated the 
> /35s...

Don't you agree that IF it's possible for prefixes longer than a /32 to 
show up in the IPv6 routing table by design (= not because of some 
uni/bilateral operator action), then the section that I quoted doesn't 
make sense and leads people to do the wrong thing?

> manage/conserve the entries in anyones routing/forwarding tables.

No, but the RIRs can sure get in the way. For instance, RIRs have 
certain minimum allocation sizes in certain IPv4 address blocks. But 
they also give out larger blocks from those ranges. (I.e., if the 
minimum for 96.0.0.0/8 is a /21, they also give out /19s and so on from 
that block.) This means operators only get to filter on the minimum and 
anyone with more than the minimum gets to deaggregate to a certain 
degree. If they would use a fixed size for each of their blocks 
instead, people who want to filter out deaggregated blocks get to do 
so.

This is just one example.

> 	The IETF (imho) should confine itself to protocol work,

So are you saying the operations and management area should go away? 
Historically, the IETF has done a lot of non-protocol work.

>   The RIRs should confine themselves to being wise stewards of the 
> addressing

Unfortunately address policy sets limits on what operators can do, so 
it's never going to work this way. And since all of this stuff is going 
to end up in routing tables world wide, regardless of the point of 
origin, it really makes no sense to decide on address policies for each 
region individually.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Nov 2004 22:22:48 +0100

> and can only justify the equivalence of a /26 you will get a /26.

There is a difference between acknowledging that they can't control how 
the operator community is going to filter, and telling the operator 
community that it's ok to filter out anything smaller than n while at 
the same tme giving out blocks that are smaller than n.

Whichever way you slice it this is WRONG. Now obviously this isn't the 
forum to keep rehashing this (those who can do something about this 
either know about the problem now or they are unwilling to fix it 
regardless of the input they receive) but I'm afraid as long as people 
are going to defend this or redefine the semantics so that it's ok 
after all, I'll have to respond and disagree.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 8 Nov 2004 22:44:03 +0100

On 2004-11-08, at 22.22, Iljitsch van Beijnum wrote:

> There is a difference between acknowledging that they can't control 
> how the operator community is going to filter, and telling the 
> operator community that it's ok to filter out anything smaller than n 
> while at the same tme giving out blocks that are smaller than n.

I don't think any RIR ever have told anyone what can and can't be 
filtered. And they can't tell the opearator community what to do. Which 
is EXACTLY why address space is given out without any guarantees of 
routability.

> after all, I'll have to respond and disagree.

You lost me. You originally wrote

> coordination of routing...  such is not the perview of either the

My point is that this is exactly what the RIRs have always done.

- - kurtis -

---

From: [email-masked]
Date: Mon, 08 Nov 2004 16:49:42 -0500

> http://www.space.net/~gert/RIPE/ipv6-filters.html

Yes, but didn't you see the "Beware of Leopard" sign on the
way down the stairs? ;)