Subject: [Softwires] Topology of the home network in draft-tsou-softwire-gwinit-6rd-01

From: Tina TSOU <[email-masked]>
Date: Mon, 08 Nov 2010 11:33:59 +0800

Consider an operator facing a high subscriber growth rate.  As a
    result of this growth rate, the operator faces pressure on its stock
    of available public IPv4 addresses.  For this reason, the operator  
is
    motivated to offer IPv6 access as quickly as possible.

    The backbone network will be the first part of the operator's  
network
    to support IPv6.  The metro network is not so easily upgraded to
    support IPv6 since many devices need to be modified and there may be
    some impact to existing services.  Thus any means of providing IPv6
    access has to minimize the changes required to devices in the metro
    network.

    In contrast to the situation described for basic 6rd [RFC5569], the
    operator is assumed to be unable to manage IP devices on the  
customer
    premises.  As a result, the operator cannot assume that any of these
    devices are capable of supporting 6rd.

    If the customer equipment is in bridged mode and IPv6 is deployed to
    sites via a Service Provider's (SP's) IPv4 network, the IPv6-only
    host needs a IPv6 address to visit the IPv6 service.  In this
    scenario, 6to4 or 6RD can be used.  However, each IPv6-only host may
    need one corresponding IPv4 address when using 6to4 or 6RD, which
    brings great address pressure to the operators.

    If the customer equipment is in routing mode, the operator has an
    opportunity to avoid assigning IPv4 addresses to sites running IPv6
    only.  Some other means is available for routing IPv6 traffic  
through
    the IPv4 network to that site.

This draft talks about "Some other means".

B. R.
Tina
http://tinatsou.weebly.com

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Nov 2010 14:39:04 +0800

Tina,

>    of available public IPv4 addresses.  For this reason, the operator is
>    The backbone network will be the first part of the operator's network

what is it that makes existing softwires mesh solutions unsuitable for crossing the IPv4 only metro network? I'm thinking specifically on 6PE or BGP tunnels.

cheers,
Ole

> 
>    In contrast to the situation described for basic 6rd [
> RFC5569
> ], the
>    operator is assumed to be unable to manage IP devices on the customer
>    only.  Some other means is available for routing IPv6 traffic through
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Tina TSOU <[email-masked]>
Date: Mon, 08 Nov 2010 18:47:23 +0800

B. R.
Tina

On Nov 8, 2010, at 2:39 PM, Ole Troan wrote:

> what is it that makes existing softwires mesh solutions unsuitable  
> for crossing the IPv4 only metro network? I'm thinking specifically  
> on 6PE or BGP tunnels.
Ole, thank you for asking. I didn't say that. IMHO, 6PE or BGP are  
more appropriately used in core network. There are fewer uses of MPLS  
in metro network. BGP tunnels are also more appropriate for core  
network.

Essentially the authors are talking about a situation where 6rd is an  
applicable technology, but needs modification to meet the constraints  
of maximized savings of IPv4 addresses and no provider access to  
customer site equipment. The IPv4 address savings occur only if the  
customer site is IPv6-only, but the proposal still works for dual- 
stack customer sites. The technical solution is to move the IPv6 in  
IPv4 tunnel endpoint to the provider edge rather than have it in  
equipment on the customer site, and use the provider gateway IPv4  
address in the IPv6 prefix given to the customer site. As Ralph  
pointed out, the protocol in RFC 5969 should be able to be applied  
without change.

The authors will restructure the draft to illustrate this latter  
point. As Ralph suggested, it will be submitted with the intention of  
becoming an Informational describing an alternative deployment of 6rd  
to meet the constraints we described above. I hope this plan meets  
with the chairs' approval.

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Nov 2010 18:53:39 +0800

Tina,

> Ole, thank you for asking. I didn't say that. IMHO, 6PE or BGP are more appropriately used in core network. There are fewer uses of MPLS in metro network. BGP tunnels are also more appropriate for core network.
> 
> Essentially the authors are talking about a situation where 6rd is an applicable technology, but needs modification to meet the constraints of maximized savings of IPv4 addresses and no provider access to customer site equipment. The IPv4 address savings occur only if the customer site is IPv6-only, but the proposal still works for dual-stack customer sites. The technical solution is to move the IPv6 in IPv4 tunnel endpoint to the provider edge rather than have it in equipment on the customer site, and use the provider gateway IPv4 address in the IPv6 prefix given to the customer site. As Ralph pointed out, the protocol in RFC 5969 should be able to be applied without change.
> 
> The authors will restructure the draft to illustrate this latter point. As Ralph suggested, it will be submitted with the intention of becoming an Informational describing an alternative deployment of 6rd to meet the constraints we described above. I hope this plan meets with the chairs' approval.

1) is BGP tunneling not applicable because these devices don't support BGP? or not support MPLS?
2) my concern with using 6rd for this purpose is that while automatic tunneling by encoding the tunnel end point in the payload address is convenient. offering a 'sensible' sized IPv6 prefix to end users is going to be problematic. note this is purely a concern from a deployment perspective. I have no doubt that you can _use_ 6rd this way. just because we _can_, _should_ we?
can you give some examples of how you deliver e.g. /56 or /64 to end users, using gi-6rd? (without expecting the SP to have a /16 of v6 space obviously).

cheers,
Ole

---

From: Alain Durand <[email-masked]>
Date: Mon, 8 Nov 2010 04:54:05 -0800

> can you give some examples of how you deliver e.g. /56 or /64 to end users, using gi-6rd? (without expecting the SP to have a /16 of v6 space obviously).

This is a critical issue.

   - Alain.

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 8 Nov 2010 14:15:13 +0000

The obvious answer is to use multiple 6rd domains and set IPv4MaskLen > 0
to save bits. Then, run the dhcp server on the GW (i.e. 6rd-CE) to
delegate prefixes to the hosts. However, what is new in this draft rfc5969
can't do?

Thanks,
Yiu

On 11/8/10 5:53 AM, "Ole Troan" <[email-masked]> wrote:

>>> what is it that makes existing softwires mesh solutions unsuitable for
>>>crossing the IPv4 only metro network? I'm thinking specifically on 6PE
>>>or BGP tunnels.
>> Ole, thank you for asking. I didn't say that. IMHO, 6PE or BGP are more
>>appropriately used in core network. There are fewer uses of MPLS in
>>metro network. BGP tunnels are also more appropriate for core network.
>> 
>>applicable technology, but needs modification to meet the constraints of
>>maximized savings of IPv4 addresses and no provider access to customer
>>site equipment. The IPv4 address savings occur only if the customer site
>>is IPv6-only, but the proposal still works for dual-stack customer
>>sites. The technical solution is to move the IPv6 in IPv4 tunnel
>>endpoint to the provider edge rather than have it in equipment on the
>>customer site, and use the provider gateway IPv4 address in the IPv6
>>prefix given to the customer site. As Ralph pointed out, the protocol in
>>RFC 5969 should be able to be applied without change.
>> 
>> The authors will restructure the draft to illustrate this latter point.
>>As Ralph suggested, it will be submitted with the intention of becoming
>>an Informational describing an alternative deployment of 6rd to meet the
>>constraints we described above. I hope this plan meets with the chairs'
>>approval.
>
>2) my concern with using 6rd for this purpose is that while automatic
>tunneling by encoding the tunnel end point in the payload address is
>convenient. offering a 'sensible' sized IPv6 prefix to end users is going
>to be problematic. note this is purely a concern from a deployment
>perspective. I have no doubt that you can _use_ 6rd this way. just
>because we _can_, _should_ we?
>can you give some examples of how you deliver e.g. /56 or /64 to end
>users, using gi-6rd? (without expecting the SP to have a /16 of v6 space
>obviously).
>
>cheers,
>Ole
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Nov 2010 22:33:57 +0800

> delegate prefixes to the hosts. However, what is new in this draft rfc5969

nothing as such. 
the difference with gi-6rd is that you also need to encode the 'customer id' in the address.

cheers,
Ole

---

From: Mark Townsley <[email-masked]>
Date: Tue, 09 Nov 2010 00:40:35 +0800

> This is a critical issue.
I certainly could be, depending on how the math works out in terms of v4
aggregates and endpoints you are supporting. Aside of breaking the /64
barrier, I can imagine it not working out well in the majority of cases.

6rd's most significant strength is when it is in support of a very large
number of sites. After the 6, 7 or 8 figure range in terms of number of
sites 6rd is enabling, the advantages vs. stateful methods become quite
apparent.

Authors, for this use-case, how many gateways are we expecting to need
to support?

- Mark

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 8 Nov 2010 21:32:10 +0000

I see the "customer id" is local to the gw. This is why I don't see a new
draft is needed. However, the major challenge is even fewer bits are
available for the CPE.

On 11/8/10 9:33 AM, "Ole Troan" <[email-masked]> wrote:

>>>>>for
>>>>more
>>>>of
>>>>point.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Nov 2010 17:08:22 -0800

> After the 6, 7 or 8 figure range in terms of number of sites
> 6rd is enabling, the advantages vs. stateful methods 
> become quite apparent.

I'm not sure that is exactly true. If there is concern for
scaling, simply add more routers/servers the same as for 6rd.

Thanks - Fred
[email-masked]

---

From: Tom Taylor <[email-masked]>
Date: Tue, 9 Nov 2010 09:18:50 +0800

One point about gateway-initiated 6rd is that the gateway IPv4 address
can be truncated, depending on the length of mask used for the network
device address space. That gives more bits for the routing part of This
should be a considerable improvement on the compression available using
straight 6rd, and gives a better chance of a 'sensibly' sized IPv6 prefix.

On 08/11/2010 6:53 PM, Ole Troan wrote:
...

> convenient. offering a 'sensible' sized IPv6 prefix to end users is
> going to be problematic. note this is purely a concern from a
> deployment perspective. I have no doubt that you can _use_ 6rd this
> way. just because we _can_, _should_ we? can you give some examples
> of how you deliver e.g. /56 or /64 to end users, using gi-6rd?
> (without expecting the SP to have a /16 of v6 space obviously).
>
> cheers, Ole
>
> _______________________________________________ Softwires mailing
> list [email-masked]

---

From: Tina TSOU <[email-masked]>
Date: Tue, 09 Nov 2010 09:45:46 +0800

For broadband services in Metro Networks, MPLS or BGP tunnel will  
cause too much cost. So they are not widely used for broadband services.
But ISPs may provide MPLS or BGP tunnel for enterprise users.

B. R.
Tina

On Nov 8, 2010, at 6:53 PM, Ole Troan wrote:

>>> for crossing the IPv4 only metro network? I'm thinking  
>>> specifically on 6PE or BGP tunnels.
>> more appropriately used in core network. There are fewer uses of  
>> MPLS in metro network. BGP tunnels are also more appropriate for  
>> core network.
>>
>> Essentially the authors are talking about a situation where 6rd is  
>> an applicable technology, but needs modification to meet the  
>> constraints of maximized savings of IPv4 addresses and no provider  
>> access to customer site equipment. The IPv4 address savings occur  
>> only if the customer site is IPv6-only, but the proposal still  
>> works for dual-stack customer sites. The technical solution is to  
>> move the IPv6 in IPv4 tunnel endpoint to the provider edge rather  
>> than have it in equipment on the customer site, and use the  
>> provider gateway IPv4 address in the IPv6 prefix given to the  
>> customer site. As Ralph pointed out, the protocol in RFC 5969  
>> should be able to be applied without change.
>>
>> point. As Ralph suggested, it will be submitted with the intention  
>> of becoming an Informational describing an alternative deployment  
>> of 6rd to meet the constraints we described above. I hope this plan  
>> meets with the chairs' approval.
>
> 2) my concern with using 6rd for this purpose is that while  
> automatic tunneling by encoding the tunnel end point in the payload  
> address is convenient. offering a 'sensible' sized IPv6 prefix to  
> end users is going to be problematic. note this is purely a concern  
> from a deployment perspective. I have no doubt that you can _use_  
> 6rd this way. just because we _can_, _should_ we?
> users, using gi-6rd? (without expecting the SP to have a /16 of v6  
> space obviously).
>
> cheers,
> Ole
>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 9 Nov 2010 09:46:23 +0800

I see I should have made sure my mail was downloaded before replying ):

...

---

From: Mark Townsley <[email-masked]>
Date: Tue, 09 Nov 2010 09:56:30 +0800

> scaling, simply add more routers/servers the same as for 6rd.
I'm referring to the overall configuration, operation and combined state
of the tunnels themselves regardless of the number of routers. Setting
up and maintaining hundreds or even thousands of configured, stateful,
tunnels is very different than hundreds of thousands, millions or tens
of millions. Alternatively, 6rd scales from small to large to very
large, at the cost of bits in the IPv6 address rather than individual
configuration and state. How expensive those bits are (or should be) is
the subject of debate in various RIR forums. If we take for granted they
are not free, then that needs to be considered when deciding which
tunneling option to deploy.

- Mark

---

From: Tina TSOU <[email-masked]>
Date: Tue, 09 Nov 2010 10:05:34 +0800

This customer ID doesn't need to be local to the GW, as when using GI  
6rd, IPV6 prefixed of different users are different. GW does the  
addressing based on the IPv6 prefix of the IPv6 addresses.

B. R.
Tina

On Nov 9, 2010, at 5:32 AM, Lee, Yiu wrote:

>>> The obvious answer is to use multiple 6rd domains and set  
>>> IPv4MaskLen >
>>> 0
>> the difference with gi-6rd is that you also need to encode the  
>> 'customer
>> id' in the address.
>>
>> cheers,
>> Ole
>>
>>>> Tina,
>>>>
>>>>>>> support IPv6 since many devices need to be modified and there  
>>>>>>> may
>>>>>>> be
>>>>>> crossing the IPv4 only metro network? I'm thinking specifically  
>>>>>> on
>>>>>> 6PE
>>>>>> or BGP tunnels.
>>>>> site equipment. The IPv4 address savings occur only if the  
>>>>> customer
>>>>> site
>>>>> prefix given to the customer site. As Ralph pointed out, the  
>>>>> protocol
>>>>> in
>>>>> an Informational describing an alternative deployment of 6rd to  
>>>>> meet
>>>>> the
>>>> 1) is BGP tunneling not applicable because these devices don't  
>>>> support
>>>> BGP? or not support MPLS?
>>>> automatic
>>>> going
>>>> space

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Nov 2010 18:18:16 -0800

Mark, 

> -----Original Message-----
> From: Mark Townsley [mailto:[email-masked]] 
> Sent: Monday, November 08, 2010 5:57 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [Softwires] Topology of the homenetwork in 
> draft-tsou-softwire-gwinit-6rd-01
> 

I'm not talking about configured tunnels; I'm talking about
automatic ones with a point-to-multipoint model. And, I'm not
talking about lots of state; I'm talking about minimal state
(say O(10) - O(100) bytes) on a per-neighbor basis. That should
provide fine scaling for a single router/server, and if further
scaling is needed just add more router/servers. 

Thanks - Fred

---

From: Mark Townsley <[email-masked]>
Date: Tue, 09 Nov 2010 11:21:28 +0800

OK, all I am trying to say is that mapping IPv4 into IPv6 address space
(ala 6rd) lets you get away with less state and configuration that would
be needed without such a mapping. Deployments which would need more
shared state and/or config (which is generally related to the number of
endpoints) have more to gain than those that do not.

- Mark

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Nov 2010 19:30:01 -0800

Hi Mark,

> endpoints) have more to gain than those that do not.

Understood, but minimal state can enable some compelling
capabilities including PI, native IPv6 prefixes that do
not embed an IPv4, MTU handling, etc.

Thanks - Fred

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 9 Nov 2010 15:09:34 +0100

Hi Tina,

>Ole, thank you for asking. I didn't say that. IMHO, 6PE or BGP are more appropriately used in core network. There are fewer uses of MPLS in metro network. BGP tunnels are also more appropriate >for core network.

This claim sounds quite strange to me: many SPs already use IP/MPLS in aggregation network segment and there are a lot of discussions both in IETF and BBF and interest from different SPs about extending the use of IP/MPLS to access segment in order to have a single technology end-to-end  (access, aggregation and core) for all services.

Best regards,
Roberta
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: lunedì 8 novembre 2010 11.47
To: Ole Troan
Cc: [email-masked]
Subject: Re: [Softwires] Topology of the home network in draft-tsou-softwire-gwinit-6rd-01

B. R.
Tina

Tina,

cheers,
Ole

If the customer equipment is in routing mode
, the operator has an
  opportunity to avoid assigning IPv4 addresses to sites running IPv6
  only.  Some other means is available for routing IPv6 traffic through
  the IPv4 network to that site.

B. R.
Tina

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.