Subject: Re: I-D Action:draft--remi-despres--ipv6-rapid-deployment--00.txt

From: Rémi Després <[email-masked]>
Date: Fri, 08 Feb 2008 17:29:45 +0100

Alexandru Petrescu a écrit :
> [email-masked] wrote:
...     :
>> draft--remi-despres--ipv6-rapid-deployment--00.txt Pages           :
>> 19 Date            : 2008-02-08
> 
> Hello Remi and thank you for this draft.  I understand the intent is to
> have it discussed at IETF.  Is the v6ops WG the right venue for this
> discussion?
I believe this would be a good choice, but there may be considerations I 
don't know about which WGs discuss what.

>  From the perspective of the end user, I have a small question on the
> decision made by this deployment to deliver a /64 prefix to the end
> user.  With only a /64 users can not subnet their networks in house, and
> use stateless address autoconfiguration at the same time;  or, some
> users already have IPv4 subnets in-house.
> 
> Is there a possibility to have for example a /56 delivered with 6rd
> method to end-user?
> 
> (I'm asking this in light of the existing 6to4 method which allows a
>  adsl-box to deliver a /48 to end user; it appears more advantageous).
Section 3.2 of the draft discusses this issue.

/64 is clearly not ideal, but is guaranteed to be possible for ISPs that 
get only /32 from their RIR's.
Free was in this case when they made the first deployment of 6rd.

I just learned that they have now a shorter prefix.
They will be able to support several subnets per customer site.

Regards.

Rémi

---

From: Rémi Després <[email-masked]>
Date: Tue, 12 Feb 2008 11:29:19 +0100

The I-D is available at:
http://www.ietf.org/internet-drafts/draft-despres-v6ops-6rd-ipv6-rapid-deployment-00.txt

(A previous file name had to be replaced by this one, more compatible 
with recommended practices, and including the now selected WG reference)

Rémi

---

From: Rémi Després <[email-masked]>
Date: Tue, 12 Feb 2008 19:31:12 +0100

Anand Kumria wrote :
> Hi Rémi,
> 
> On 2/12/08, Rémi Després <[email-masked]> wrote:
>> The I-D is available at:
>> http://www.ietf.org/internet-d​rafts/draft-despres-v6ops-6rd-i​pv6-rapid-deployment-00.txt
> 
> Perhaps I am being very dense but how does this work, considering:
> 
> - you (free.fr) have a /32 from RIPE-NCC
> - you have a IPv4 address (for the CPE) encoded in 32 bits
> 
> The network portion of your 64 bits is now gone.
Yes.
Until Free a shorter prefix than /32 frpm the RIPE, their customer sites 
have only one IPv6 link (but this is sufficient to most).
Now that Free has received a shorter prefix they can change their 6rd 
ISP prefix and will be able to permit multiple subnets in their customer 
sites.

> You've lost the ability to specify your IPv6 6rd prefix?
> 
> I realise that you've set aside a portion your the address space
> contained with the (i.e. RIPE-NCC+110/36) to be what you use for
> "Pure" IPv6 so, what do you specify to your CPEs as the 6rd ISP
> prefix? The whole /32 allocation?

The 6rd ISP prefix is the /32 itself.
Since none of the v4 addresses they assign starts with 1110 there is no 
confusion.

Rémi

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 12 Feb 2008 22:27:46 +0200

> with recommended practices, and including the now selected WG reference)

Lets clear: /64 subnet at the CPE plain simply SUCKS. Badly.

Next thing is IPv6 NAT, when people try to "cascade" access points/routers 
within their home network. Like it or not, CPEs MUST get more than /64, and 
MUST support downstream prefix delegation.

Last time I checked, Free was not assigned the whole IPv4 address space. I 
assume they don't want to provide the Rapid Deployment service to customers 
of *other* ISPs. So while they do only have a /32 IPv6 prefix, they don't 
need to burn 32 further bits to keep track of each of the IPv4 address of 
each of their customers. Storing the 24 lower order bits should be 
sufficient. And this leaves 64-32-24=8 rouable bits per customer.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Rémi Després <[email-masked]>
Date: Tue, 12 Feb 2008 23:52:07 +0100

> Lets clear: /64 subnet at the CPE plain simply SUCKS. Badly.
WOW!
Please note that many users now have real IPv6, without any NAT 
traversal tricks, thanks to the proposed new technique, and thanks to 
its first deployment by Free (which for some practical reasons was 
initially limited  to /64 prefixes).
On my home LAN, it doesn't suck at all. It just works to my complete 
satisfaction.
Clearly it is desirable to do much better than this /64 first step, but 
one step after another is sometimes a good way to progress.

In view of your strong reaction though, the following sentence will have 
IMO to be rewritten:
"This is expected to be satisfactory initially for the vast majority of 
residential sites, where the number of hosts is small."

> within their home network.
You are free to believe that IPv6 to IPv6 NATs would be the proposed 
next step.
But not by me, for sure.

>Like it or not, CPEs MUST get more than /64, and 
Where did you get that I might not like shorter than /64 prefixes !!!.

I wrote myself that /64 "is a real restriction which would 
advantageously be avoided with RIRs cooperation" (sec. 3,2).

Free has already obtained a shorter than /32 prefix, just to have 
multiple subnet customer sites.

> sufficient. And this leaves 64-32-24=8 rouable bits per customer.

You are right, they could have done that.
But IMO the additional complexity would not have been justified, 
especially since it was expected to be only provisional.
It would also have made addresses less readable.

Section 3.2 says:
"In view of the potential of 6rd to facilitate IPv6 availability, RIRs 
could be advised to consider assigning /24 prefixes to ISPs that
deploy 6rd, and to endorse that these ISPs make their first IPv6 
deployments with /56s distributed to their customers."

May be more flexibility on this point would be appropriate, in 
particular by relaxing the restriction that 6rd ISP prefixes are 
multiple of 8 bits.

Rémi

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 13 Feb 2008 00:13:38 +0100

Hi Rémis,

> sufficient. And this leaves 64-32-24=8 rouable bits per customer.

No, /24 is still too much (only two or three ISPs have that much IPv4  
space) and too little (fills up an entire IPv6 /32) at the same time.  
What should happen here is that the actual allocation size is used. So  
if an ISP has a /19, they use up /56 - /19 = /37 for the customers in  
that /19.

---

From: Remi Denis-Courmont <[email-masked]>
Date: Wed, 13 Feb 2008 10:52:49 +0100

On Tue, 12 Feb 2008 23:52:07 +0100, Rémi Després <[email-masked]>

> one step after another is sometimes a good way to progress.

The IETF has a long history of doing "provisional" "for a short time"

protocols that eventually last much much longer than intended. NATs are

one. And 6to4... it was standardized over 5 years ago, and we are only now

realizing that it does not work as well as intended. When we know that

something is wrong or broken to begin with, we definitely should not

standardize it in the first place, IMHO. That will not prevent Free from

using it anyway.

> residential sites, where the number of hosts is small."

The number of hosts is totally irrelevant.

I have been on switched IPv6 subnets with hundreds of boxes without any

problem.

The issue is with *cascading* routers. With no bits to do routing within a

site, if bridging is not possible, there is no choice but to use NAT.

> But not by me, for sure.

So what if I plug a cheap SOHO router behind my CPE?

> But IMO the additional complexity would not have been justified,

Where is the complexity in shifting some bits?

> It would also have made addresses less readable.

That assumes humans can convert decimal IPv4 address to hexadecimal fast

enough to "read" them.

Also, this only works for /32+32 and /16+32 prefixes, neither of which look

like a good compromise.

I'd happily preserve statelessness, and get saner prefixes size at the

expense of readability. IPv6 addresses are pretty much unreadable anyhow.

-- 

Rémi Denis-Courmont

http://www.remlab.net

---

From: Rémi Després <[email-masked]>
Date: Wed, 13 Feb 2008 13:58:04 +0100

Iljitsch van Beijnum wrote :

> So if an ISP has a /19, they use up /56 - /19 = /37 for the
customers

> in that /19.

If an ISP has a /19 and assigns  /56s  with 6rd to its customers,  the
computation is as follows:

Let XXXX:e000::/19 be the ISP prefix.

Let XXXX:e000::/24 be its chosen 6rd ISP prefix.

Then, 6rd  site prefixes are :

XXXX:e0AA:AAAA:AA00::/56,

where Y is "e" or "f",

the first A is not e

AAAAAAAA is the site v4 address

Prefixes left for pure v6 sites are then:

(a full /19  -  (a full /24 - (a full /28)))

In other words, *less than  1/32th* of the space has been used for 6rd.

( 1/32 = 1 / 2 ^ [24 - 19] )

With that practically negligible consumption, what has been bought is
the capability to rapidly assign /56s to all v4 sites of ISPs .

Note also that, once v4 addresses are no longer necessary for customer
sites, this 1/32 of the space can be reused for pure v6 sites.

Rémi

---

From: Rémi Després <[email-masked]>
Date: Wed, 13 Feb 2008 14:22:01 +0100

Remi Denis-Courmont wrote :

> The issue is with
*cascading*routers. With no bits to do routing

> within a site, if bridging is not possible, there is no choice but
to

>  use NAT.

There is IMHO a better alternative:  where no IPv6 prefix is available,

like behind a cascading router in a /64 site, use another available
tool.

(Teredo, tunnel broker etc, are IMU availble precisely for this).

> Where is the complexity in
shifting some bits?

Right, "shifting bits" is simple.

It works if each ISP hasonly one RIR-provided prefix for all its
customers,

but *only in this case*.

Personally I don't know how many v4 prefixes Free has, and plans to use.

But, as you know,  ISPs tend to get their v4 address space piece by
piece.

The complexity starts.

Rémi

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 13 Feb 2008 21:29:40 +0100

On 13 feb 2008, at 13:58, Rémi Després wrote:

> If an ISP has a /19 and assigns  /56s  with 6rd to its customers,   
> the computation is as follows:

> Let XXXX:e000::/24 be its chosen 6rd ISP prefix.

I'm not sure what you are trying to say here... Can you explain a bit  
more what the message I'm replying to is about? Are you agreeing with  
me, suggesting something new or clarifying something old?

---

From: Rémi Després <[email-masked]>
Date: Wed, 13 Feb 2008 22:39:25 +0100

> me, suggesting something new or clarifying something old?

You wrote "if an ISP has a /19, they use up /56 - /19 = /37 for the 
customers in that /19."

I am not sure myself what was your point.
I was then trying  to clarify how much of the ISP /19 prefix is used for 
6rd (with a longer answer than the quotation above).

Unless you see a need to discuss this further, we probably can leave it now.

Rémi

---

From: Remi Denis-Courmont <[email-masked]>
Date: Fri, 15 Feb 2008 09:42:57 +0100

On Wed, 13 Feb 2008 14:22:01 +0100, Rémi Després <[email-masked]>

wrote:

> > The issue is with *cascading* routers. With no bits to do

> > routing within a site, if bridging is not possible, there

> > is no choice but to use NAT.

> There is IMHO a better alternative:  where no IPv6 prefix is

> available, like behind a cascading router in a /64 site, use

> another available tool.

> (Teredo, tunnel broker etc, are IMU availble precisely for this).

Neither Teredo nor TSP are suited in that case. You'd have to go to the

Internet to reach hosts from the same site, but within different subnets.

There is a reason why native IPv6 access and normal 6to4 are giving more

than 64-bits. It's precisely because the solution to this problem is

Prefix-Delegation.

> It works if each ISP hasonly one RIR-provided prefix for all

> its customers,  but *only in this case*.

Makes no difference how many prefixes the ISP has. In any case, the

ISP-side endpoint needs to know the prefixes so that it cannot be abused by

external users from other ISPs. Moving this issue away from the 64rd ISP

endpoint and its addressing scheme to yet another box (a firewall, right)

is arguably even more complicated, in fact.

> Personally I don't know how many v4 prefixes Free has,

> and plans to use. But, as you know,  ISPs tend to get

> their v4 address space piece by piece.

So? 64rd cannot avoid the problem anyway.

-- 

Rémi Denis-Courmont

http://www.remlab.net

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 15 Feb 2008 17:21:12 -0800

Disclaimer: for several days others have been telling me I am mis-reading
this draft.

That said, my interpretation is that this is broken, despite a quick hack
deployment. In any case, I don't believe the proposed fixes would be
difficult changes for the existing deployment and will result in a cleaner
solution.

Despite the elaborate Intro & Principles discussion, to clarify what I think
the goals are:

1) automate ISP controlled tunnels over IPv4-only aggregation equipment.

2) assign customer prefixes within ISP's delegated RIR prefix to contain the
size of the IPv6 DFZ

Discussion:

This general approach actually works well in the downstream direction as a
tool to automate PE to CPE tunneling. The PE already has to be provisioned
with the aggregating prefix for its downstream customers, so this is really
just an automated neighbor resolution process on the back end across the
IPv4-only aggregation equipment. A BCP describing how to align an IPv6
aggregating prefix for automated PE tunneling would be a good thing,
independent of this draft. The upstream direction is another story though.

Problems:

1) 'pure' tag makes a questionable assumption in light of unresolved and
continuing RIR discussions about changing the status of 240/4.

2) causes ISPs to allocate unnaturally large prefixes to pops to accommodate
a mostly unused 32-bit field

3) the 3.5 discussion about accepting prefixes from other ISPs that might
contain a 6rd anycast is just wrong. First there is no way for an ISP to
know which prefix its peer is using for a 6rd relay. Second, there is no
reason to preclude it since the IPv6 6rd prefix would not match for their
sites, and the local CPE would not be configured for the other ISP's
anycast, so the local CPE would never be attempting to send to the other
ISP's 6rd anycast relays even if there is a route. 

Fixes:

Option 1) provide the IPv4 prefix & length:4 (really only need length:4
since CPE already has addr), as well as IPv6 prefix & length:6. Extract bits
(32-length:4) following IPv6 prefix/length:6, then append to IPv4 prefix to
create IPv4 next-hop.
Pro: PE allocation size is the same for both versions  
Con: CPE can only directly see its containing IPv4 aggregate 
Resolution: DHCP option includes list of IPv4 prefixes & lengths that are
directly reachable
Alternate Resolution: PE sends redirect for any other prefix in the IPv4 IGP
Con: CPE can't tell if a neighbor is tunneled or native
Resolution: all CPE attached to a PE must move at the same time to a prefix
shorter than the ISP-wide 6rd one, or PE must host its portion of the
shorter native prefix as well as the 6rd one.
	(much cleaner than assuming 224/3 is never a valid IPv4 dst)

Option 2) CPE always initially sends to PE, PE sends redirect for anything
the CPE should be able to reach as indicated by the IPv4 IGP
Pro: CPE defers routing decision to PE
Pro: CPE configuration is just a 4213 manual tunnel
Con: CPE router may ignore redirect
Resolution: Requires spec so CPE will accept redirect from the upstream
router
Con: increases load on PE to generate redirects
Resolution: CPE caches redirects for the lifetime of its DHCP lease
	(if redirect included length:4, the CPE could figure out the rest of
that aggregate)

Tony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rémi Després
> Sent: Tuesday, February 12, 2008 2:29 AM
> To: [email-masked]
> Subject: 6rd - Rapid Deployment on existing IPv4 infrastructures - a
> new approach
> 
> The I-D is available at:

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Feb 2008 16:49:30 +1300

>> one step after another is sometimes a good way to progress.

As long as any ISP deploying /64 to SOHO customers also has a way to
provide a /48 to any customer who wants to subnet their network, at
negligible extra cost, this could be OK. But customers who need /48
(or /56) must not be blocked.
> realizing that it does not work as well as intended. 

As far as I know, nobody has deployed it as intended by RFC 3056.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 18 Feb 2008 09:51:51 +0100

> ISP's 6rd anycast relays even if there is a route.

What is a "6rd anycast address", anyway? I couldn't figure it out from  
the draft. The definition certainly isn't helpful:

   6rd ISP anycast address: IPv4 anycast address chosen by a 6rd ISP

 From what you're saying it sounds an awful lot like what happens with  
6to4, but that doesn't make any sense because we already have 6to4 and  
although that's certainly useful, it has the downside that it's  
impossible to improve the quality of the 6to4 experience. So the basic  
idea of something that is as simple to set up as 6to4 but where the  
routing is under control of an ISP is very attractive.

---

From: Gert Doering <[email-masked]>
Date: Mon, 18 Feb 2008 14:38:51 +0100

Hi,

On Mon, Feb 18, 2008 at 09:51:51AM +0100, Iljitsch van Beijnum wrote:
> 6to4, 

Basically it's a locally-contained 6to4 cloud using IPv6 addresses 
delegated to the provider, instead of 2002::/16.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  110584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Mon, 18 Feb 2008 15:02:41 +0100

Hi,

> get only /32 from their RIR's.

Using a more intelligent mapping function than "always use full 32 bit"
for the mapping IPv4-Address <-> IPv6-Prefix would solve this.

For example, if an ISP only has a /16 IPv4 address space, they could
map this to a /48 IPv6 per end user, inside their IPv6 space:

  </32 prefix from RIPE><lower 16 bits of CPE IPv4 address>::/48

- as the upper 16 bits are the same for all subscribers anyway.

Tony Hain has brought up some approaches how to get the mapping table
to the CPEs.

Another thing could be to just statically provision the mapping tables 
("<this> range is 6rd, use point-to-point 6to4 tunnels - and all the rest 
is native, send to PE") in the CPEs at roll-out - as most ISPs do not get 
new IPv4 blocks *that* often.

Or provision them at "automated centrally managed software update" time.

Gert Doering
        -- NetMaster

---

From: Rémi Després <[email-masked]>
Date: Mon, 18 Feb 2008 15:38:04 +0100

The point being discussed is IMU simplicity vs functional richness.

IMO, the "normal" 6rd is with a /24 ISP prefix, allowing for /58s  site 
prefixes.
Yet, to start quickly, as Free did it, /64s are nice to have instead of 
nothing.

Note that if a site has a shorter than /32 IPv4 prefix, say a /28, then 
it has with 6rd the desired multi-subnet capability with 6rd. (Free 
happens to only assign /32s in IPv4).

Note also that ISPs typically have their IPv4 prefixes coming one by 
one, with different lengths.
Free's IPv4 prefixes, for example, are of lengths /16, /15, /14, two 
/11s, /10.
he simple solution of your example couldn't apply.
The code to deal with this, instead of being trivial, and with fixed 
length parameters, would bacome significantly more complex.
The DHCP option also would be substantially lesss simple

RD

---

From: Gert Doering <[email-masked]>
Date: Mon, 18 Feb 2008 16:13:34 +0100

Hi,

> he simple solution of your example couldn't apply.

It would work just fine.  The tables would be a bit less trivial, but to
map 6 prefixes of maximum length /10 into 24 bits worth of IPv6 prefixes
is well possible.

> length parameters, would bacome significantly more complex.

The code would need to consult a mapping table, indeed.

Which is not very advanced magic.

Gert Doering
        -- NetMaster

---

From: Rémi Després <[email-masked]>
Date: Mon, 18 Feb 2008 16:52:43 +0100

> Which is not very advanced magic.
I can only agree, of course.
A table IS indeed possible. It can replace of a simple parameter.
Its maximum length will be somewhat arbitrary, but I am sure it can also 
be lived with.
It would make operations and maintenance more complex (address 
readability in particular), but again, you re right, that's clearly 
possible.

But the "Keep It Simple, Stupid" principle was a guide.
In this instance, I still believe that keeping a KISS design is preferable.

Note also that, if 256 ISPs deploy 6rd as is, and if all of them get 
/24s for that (so that 256 IPv6 subnets are available per site having an 
IPv4 address).
Then, the address space consumed is less than that used for 6to4 (256 
/24s, partially used, vs one /16). If this does facilitate IPv6 rapid 
deployment, in particular because it follows the KISS rule, this seems 
to me a reasonable price to be paid.

Can we discuss this issue in Philadelphia?

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 19 Feb 2008 09:20:44 +0100

Thanks for your detailed comments.

> continuing RIR discussions about changing the status of 240/4.
OOPS
There is a typo: 1110 as most significant bits is 224/4 (not 240/4 as
written once).
Apologies.
> a mostly unused 32-bit field
See the answer to Gert Doering:
http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00345.html
> ISP's 6rd anycast relays even if there is a route. 
There must be a misunderstanding.
An ISP never needs  to know 6rd anycast addresses of other ISPs.
Routes an ISP has to make sure to refuse, if received by accident or
malevolence, are routes to their OWN 6rd anycast prefix.
It can be made clearer in the next version.

RD

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 19 Feb 2008 11:01:50 -0800

> There is a typo: 1110 as most significant bits is 224/4 (not 240/4 as

The tag is a waste to begin with, so fixing which block it talks about
doesn't really solve the problem.

> http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00345.html

A quick hack that is deployed does not mean this is a good design. The
deployment could also have taken one /38 and handed out /48's to customers,
then put all the native IPv6 sites in a different /38 (note: both fit well
within the /32). Any CPE could find the others within the ISP because the
/38 matches, and anything else would go to the relay. No need for a magic
flag. No need for oversize allocations to deliver undersize prefixes to
customers. 

> It can be made clearer in the next version.

   For an ISP to guarantee proper routing of IPv6 packets going from its
   IPv4 sites to other ISPs, its IPv4 infrastructure SHOULD NOT accept
   from other ISPs IPv4 routes that include the 6rd ISP anycast address.

If this is just saying 'don't accept your prefixes from another provider',
it is not clear that you even need to say that. 

Tony