Subject: [v6ops] 6rd Sunsetting

From: Mark Townsley <[email-masked]>
Date: Tue, 15 Nov 2011 16:01:54 +0800

Alexandre and I just finished up a -00 that describes two methods for moving a 6rd deployment to native IPv6. Apologies for not getting this out before the meeting.

http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt

Abstract

   This document provides guidelines for transitioning an IPv6
   deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment
   using Native IPv6.  It is targeted at both 6rd operators and 6rd
   implementors."

- Mark

---

From: Hans Liu <[email-masked]>
Date: Tue, 15 Nov 2011 16:17:49 +0800

Excuse me Mark, I still don't have an idea in what kind of use case
should we have 6rd and Native Dual Stack at the same time in the
network?

Regards,
Hans

On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley <[email-masked]> wrote:
>
> Alexandre and I just finished up a -00 that describes two methods for moving
> a 6rd deployment to native IPv6. Apologies for not getting this out before
> the meeting.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

-- 
Instead of following the fashion, we lead it through.

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 15 Nov 2011 09:31:26 +0100

Why not.  Apart from the described scenario in this draft (which in fact is a temp 6rd/native setup), you could also have some CPE deployment using multiple Wan intfs, one of them being native, another one of them not (yet) native, using 6rd.

Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
[email-masked]
tel.: +32 3 443 65 90

Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

Help preserve the color of our world - Think before you print.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hans Liu
Sent: dinsdag 15 november 2011 9:18
To: Mark Townsley
Cc: Alexandre Cassen; [email-masked] WG; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

Excuse me Mark, I still don't have an idea in what kind of use case should we have 6rd and Native Dual Stack at the same time in the network?

Regards,
Hans

On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley <[email-masked]> wrote:
>
> Alexandre and I just finished up a -00 that describes two methods for 
> moving a 6rd deployment to native IPv6. Apologies for not getting this 
> out before the meeting.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Nov 2011 09:34:45 +0100

In your previous mail you wrote:

=> Mark used the word "moving" which IMHO strongly suggest we don't
have both 6rd and native dual stack at the same time, doesn't it?

Regards

[email-masked] (happy user of 6rd and surely even more happy
with native IPv6 :-)

---

From: Mark Townsley <[email-masked]>
Date: Tue, 15 Nov 2011 16:45:54 +0800

> have both 6rd and native dual stack at the same time, doesn't it?

Both methods described in the document are incremental, one requiring renumbering and the associated (general) issues with that, the other not. In either case, you will have 6rd and native at the same time in the network as you move subscribers over time. 

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Tue, 15 Nov 2011 16:46:41 +0800

> should we have 6rd and Native Dual Stack at the same time in the

Incremental transition from 6rd to native. 

- Mark

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 15 Nov 2011 09:48:10 +0100

Question: In case the CPE must be able to cope with an identical IPv6 PD, as in
""
6rd and native IPv6 MUST allow for an identical IPv6 delegated
       prefix.
""
Then how does it exactly work with timer updates (as they might be different and done on different times by both mechanisms) ?

Carl Wuyts
Connect Division

[email-masked]<mailto:[email-masked]>
tel.: +32 3 443 65 90
<http://twitter.com/#!/TechnicolorIPv6>
<http://www.technicolor.com/>
Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Townsley
Sent: dinsdag 15 november 2011 9:02
To: [email-masked] WG
Cc: Alexandre Cassen
Subject: [v6ops] 6rd Sunsetting

Abstract

   implementors."

- Mark

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Nov 2011 09:55:40 +0100

Both methods described in the document are incremental, one requiring
   renumbering and the associated (general) issues with that, the other
   not. In either case, you will have 6rd and native at the same time in
   the network as you move subscribers over time.
   
=> I am a bit subscriber oriented (perhaps because I am myself
a 6rd user) so I read the question about use case as can a subscriber
be provided with both 6rd and native IPv6 service at the same time
by an ISP? and IMHO the answer is in general no.

Regards

[email-masked]

PS: do you have contacts at Illiad/Free to apply one of your methods?
(of course I'd prefer the not renumbering one)

---

From: Mark Townsley <[email-masked]>
Date: Tue, 15 Nov 2011 17:11:28 +0800

> by an ISP? and IMHO the answer is in general no.

For the simple singlehomed user, the user should either notice nothing at all when being transitioned from 6rd to native ("seamless" mode described in the draft) or witness a renumbering. The service to the end-user before and after should be essentially the same.

For multihoming, I don't know why we would limit 6rd and native to two separate ISPs any more than we would limit two native connections to two ISPs. It's clearly not the common case, but inasmuch as multihomed CPEs exist, one could be native and the other 6rd.

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Nov 2011 22:13:33 +1300

Mark,

I will read the draft when a calm moment arrives. But I have to ask,
what is its relationship to RFC 6264? That already includes 6rd
as one option in the path to v6ness.

Regards
   Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Nov 2011 17:16:36 +0800

i want cgn sunsetting.  or how about ds-lite eclipse?

---

From: Mark Townsley <[email-masked]>
Date: Tue, 15 Nov 2011 17:37:20 +0800

> as one option in the path to v6ness.

This is very specific for 6rd to native (no CGN, ds-lite, etc), and, importantly, includes specific requirements for CPE implementors. Relevant as 6204-bis has brought 6rd into its scope. 

I look forward to your review, and whether it is in conflict in anyway with 6264 in your mind.

- Mark

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 15 Nov 2011 10:33:03 -0500

I have a few comments on the proposed 6rd Sunsetting doc.

1. Since CE Routers can't predict whether an access network will choose
to renumber or keep numbers the same, it must be prepared to handle
either. Recommendations for CE routers need to be provided that account
for both cases, and do not require the CE router to know, a priori,
which will be used (that is, there should be no expectation of differing
configuration in the CE router, depending on what the access network
decides to do). [This draft is written from the access network
perspective. For good CE router recommendations, it needs to look at it,
holistically, from the CE router perspective.]

2. There is an assumption in some of the text in this draft that CE
routers inside the 6rd domain will always route directly to each other,
without going to the BR. Note that we've specifically asked for it to be
configurable as to whether or not this is the case. Therefore, some CE
routers may be configured to send all IPv6 traffic to the BR. I don't
think this necessarily changes the recommendations, but it should change
some of the language used to justify the recommendations.

3. The following phrase is used a couple of times, and is a bit fuzzy,
IMO: "6rd routes remain [in the CE router] as long as 6rd is configured
by the SP". When 6rd is configured by DHCPv4 or TR-069 or SNMP, it's
clear to me what this means. But when the CE router was manually
configured for 6rd, I have no clue what this means. How is the
manually-configured CE router supposed to know whether or not 6rd is
configured by the SP? Some guidance in this area would be appreciated.
For example, should the CE router test to see if the BR is reachable,
and if not assume that 6rd is not configured by the SP?

Barbara 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Townsley
Sent: Tuesday, November 15, 2011 3:02 AM
To: [email-masked] WG
Cc: Alexandre Cassen
Subject: [v6ops] 6rd Sunsetting

Abstract

- Mark

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 16 Nov 2011 09:56:15 +0800

Mark,

In section 5 (Sunsetting without renumbering), the impacts on the routing
environment may be needed in the discussion.

As an example, when we developed our routing architecture for IPv6, it did
not follow how IPv4 prefixes/blocks were distributed in the network due to
limitations of how IPv4 had to go out.

So, if the CE needs to retain the PD (as calculated by 6rd), then this may
have impacts (considerations) on the IPv6 routing architecture.  I am not
saying this is bad or good, but should be considered.  An operator may
need to make changes upfront to keep routing aggregation intact.

Regards,

Victor K

On 11-11-15 5:37 PM, "Mark Townsley" <[email-masked]> wrote:

>This is very specific for 6rd to native (no CGN, ds-lite, etc), and,
>importantly, includes specific requirements for CPE implementors.
>Relevant as 6204-bis has brought 6rd into its scope.
>

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 16 Nov 2011 10:00:28 +0800

Mark,

At second pass, I noticed you actually addressed this in section 5,
subsection 5/6.  I missed this nuance at first pass - sorry.

Regards,

Victor K

---

From: Fred Baker <[email-masked]>
Date: Wed, 16 Nov 2011 15:03:03 +0800

The use cases I can think of are:

1) I used to run 6rd and have now deployed native service, but have not yet turned 6rd off.
2) I am using 6rd in one place and native service somewhere else.

The second case is a pretty common coexistence case, I should think, but the two configurations don't conflict because they are different parts of the network. The first case is one that is presumably transitory but will be common during a switchover.

I think the argument for thinking about routing is to direct traffic to the wider PMTU when possible and to have native deployment obsolete 6rd deployment quickly. If the route metrics are the same, one would expect some traffic to use native and some to use 6rd connectivity, which could be confusing for someone expecting the 6rd traffic to go to null.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Nov 2011 03:01:39 -0600

Folks,

The use cases that Fred outlined are exactly what we authors of the
document considered and the text in section 4.4.3 of the rfc6204bis
document reflects the fact.  The relevant text for the section is the
first paragraph of the section, bullets 1, 2, 5, and 6, and the last
paragraph covers sunsetting of 6rd. 
 
http://tools.ietf.org/id/draft-ietf-v6ops-6204bis-02.txt

Thanks, Fred.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fred Baker (fred)
Sent: Wednesday, November 16, 2011 3:03 PM
To: Hans Liu
Cc: Alexandre Cassen; [email-masked] WG; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

1) I used to run 6rd and have now deployed native service, but have not
yet turned 6rd off.
2) I am using 6rd in one place and native service somewhere else.

The second case is a pretty common coexistence case, I should think, but
the two configurations don't conflict because they are different parts
of the network. The first case is one that is presumably transitory but
will be common during a switchover.

I think the argument for thinking about routing is to direct traffic to
the wider PMTU when possible and to have native deployment obsolete 6rd
deployment quickly. If the route metrics are the same, one would expect
some traffic to use native and some to use 6rd connectivity, which could
be confusing for someone expecting the 6rd traffic to go to null.

>> Alexandre and I just finished up a -00 that describes two methods for
moving

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Nov 2011 18:16:00 -0600

Chairs,

Please also note from the email below that the rfc6204bis has no
dependency on any Softwires 6rd sunsetting document.   The rfc6204bis
document 6rd sunsetting text is already complete.

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Wednesday, November 16, 2011 5:02 PM
To: Fred Baker (fred); Hans Liu
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

Folks,

http://tools.ietf.org/id/draft-ietf-v6ops-6204bis-02.txt
<http://tools.ietf.org/id/draft-ietf-v6ops-6204bis-02.txt> 

Thanks, Fred.

Hemant

-----Original Message-----

moving

v6ops mailing list

[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 17 Nov 2011 00:29:03 -0500

In reading through the 6rd sunsetting draft vs. 6204bis, I think we may
not have fully covered the case (in 6204bis) where the same prefix is
used for 6rd and native. In this case, the philosophy of "route based on
source address" won't work, and we should probably use the "metric"
approach proposed by the 6rd sunsetting draft. We also can't unprefer
and invalidate the prefix to the LAN.

So perhaps the items in 6204bis become:

   5.  Selection of 6rd tunnel or native IPv6 output interface on the CE

       router is determined by the source IPv6 address of the packet

       from a host, when different prefixes are available over 6rd vs.
native IPv6 (IA_PD). 
       If the two interfaces provide the CE router with the same prefix,
then the 
       CE router assigns a forwarding metric such that native IPv6
       egress is preferred when 6rd
       and native IPv6 interfaces are active.

   6.  The CE router informs hosts that the native IPv6 prefix is
preferred over the 

       6rd prefix, in the case where the two interfaces use different
prefixes.

Barbara

Sent: Wednesday, November 16, 2011 4:02 AM

Folks,

Thanks, Fred.

Hemant

-----Original Message-----

moving

v6ops mailing list

[email-masked]

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Nov 2011 23:57:24 -0600

Barbara,

Agreed.    We had the metric as part of an earlier revision of text
emailed to the cpe router mailer but during editing we missed putting
the same prefix back to the text.  Good catch.

Thanks,

Hemant

From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Thursday, November 17, 2011 1:29 PM
To: Hemant Singh (shemant); Fred Baker (fred); Hans Liu
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: RE: [v6ops] 6rd Sunsetting

Barbara

Folks,

Thanks, Fred.

Hemant

-----Original Message-----

moving

v6ops mailing list

[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Nov 2011 17:04:16 +0800

Personally, I'd be a bit perplexed at putting native and 6rd deployment into the same prefix. I could imagine adjacent prefixes - one is 2001:dba:2:2::/64 and the other is 2001:dba:2:3::/64. But to my way of thinking, the prefix in effect chooses the path to the place the prefix is located. The reason for source select routing is the issue raised in BCP 84: BCP 38 will drop traffic if it takes the wrong path, so please route outbound traffic on the correct path. If two paths have the same prefix, then either we're looking at ECMP, or we have a situation in which the router's tables are ambiguous...

On Nov 17, 2011, at 1:29 PM, STARK, BARBARA H wrote:

> In reading through the 6rd sunsetting draft vs. 6204bis, I think we may not have fully covered the case (in 6204bis) where the same prefix is used for 6rd and native. In this case, the philosophy of “route based on source address” won’t work, and we should probably use the “metric” approach proposed by the 6rd sunsetting draft. We also can’t unprefer and invalidate the prefix to the LAN.
>  
>        from a host, when different prefixes are available over 6rd vs. native IPv6 (IA_PD). 
>        If the two interfaces provide the CE router with the same prefix, then the 
>    6.  The CE router informs hosts that the native IPv6 prefix is preferred over the
>        6rd prefix, in the case where the two interfaces use different prefixes.
> Barbara
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
> The use cases that Fred outlined are exactly what we authors of the document considered and the text in section 4.4.3 of the rfc6204bis document reflects the fact.  The relevant text for the section is the first paragraph of the section, bullets 1, 2, 5, and 6, and the last paragraph covers sunsetting of 6rd.
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker (fred)

---

From: Mark Townsley <[email-masked]>
Date: Thu, 17 Nov 2011 18:12:30 +0800

On Nov 17, 2011, at 5:04 PM, Fred Baker wrote:

> Personally, I'd be a bit perplexed at putting native and 6rd deployment into the same prefix.

I agree, it is not the most obvious solution, and the draft says that. But, once you run through it until the end, it has some compelling aspects. 

> I could imagine adjacent prefixes - one is 2001:dba:2:2::/64 and the other is 2001:dba:2:3::/64.

Unfortunately. that's not possible with the way that 6rd operates.

> But to my way of thinking, the prefix in effect chooses the path to the place the prefix is located.

If it follows normal routing, it of course chooses the path based on the destination, not the delegated prefix. 

> The reason for source select routing is the issue raised in BCP 84: BCP 38 will drop traffic if it takes the wrong path, so please route outbound traffic on the correct path.

Using the same delegated prefix avoids this (our #2 scenario), using different prefixes (scenario #1) causes us to have to deal with this problem. Source select routing is something that needs to be solved, and is on the list of things we are worrying about in homenet, but AFAIK it is beyond the current state of the art. 

> If two paths have the same prefix, then either we're looking at ECMP, or we have a situation in which the router's tables are ambiguous...

The draft specifically says that the native path should have a preferred metric. Alternatively, an implementation could remove the default route to the 6rd virtual interface, but that would require some coupling between interfaces, something that I was trying to avoid. 

So, I don't see the ambiguity. With 6rd and native up, there are at most 3 routes. One more-specific that points to the CE-CE 6rd tunnel, the other one or two that point to native or 6rd BR upstream, but with a preference for native over 6rd.

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2011 23:24:07 +1300

Fred,

Who is applying BCP38? I assume the 6rd operator can figure out that however the
traffic arrives, it is from the appropriate CE, because in the 6rd world, the
operator provides and configure the CE anyway. There would just be the same
BCP38 filter on both paths.

Regards
   Brian

On 2011-11-17 22:04, Fred Baker wrote:
> ------------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2011 23:39:41 +1300

Major comments first:

I like. I have just re-read section 3 "Smooth Transition towards IPv6
Infrastructure" of RFC 6264 and I think it fits with your model
almost seamlessly. (If you re-read it, remember that 6264 makes two
assumptions: ISPs will run CGNs whether we like it or not, and the
CGN as described in 6264 coexists with a 6rd decapsulator.) If you
agree with this you could easily add an informative reference to
6264.

>    4.  When native IPv6 becomes active on a given CE, an upstream
>        default route is installed for IPv6 as it normally would, while
>        assigning a metric that causes the native link to be preferred
>        over 6rd. 

I assume you mean that a *second* /128 route is installed, with
the first one being provisioned as part of the pure 6rd phase.

>                  6rd routes remain as long as 6rd is configured by the
>        SP, allowing the more-specific route for inter-domain 6rd traffic
>        to be selected over the native route (again, following normal IP
>        forwarding rules).  

Which "6rd routes"? This is the first time you mention them. Do you mean
that as well as the default (/128) route, there is also a specific
route for the local 6rd prefix (e.g. a /32)?

Minor:

>    Unlike 6to4 [RFC3056], 6rd is designed to be configured and operated
>    by an SP.  

Actually RFC3056 *was* intended to be a managed solution configured and
operated by enterprise and SP operators. The one you mean to insult
is Anycast 6to4 [RFC3068].

>    Using this mode, end-user sites are renumbered when moving from 6rd
>    to native IPv6.  Recommendations for "Renumbering Without a Flag Day"
>    described in [RFC4192] should be followed.

I wish it was that simple; it isn't really, which is why we have just started
6RENUM. It would be useful if you could look at the various draft-*-6renum
drafts to see if we have missed any issues that will come up during your
sunset.

In any case, why would anybody want to use the renumbering model if you
can make the non-renumbering model work properly?

Regards
   Brian

---

From: Shishio Tsuchiya <[email-masked]>
Date: Thu, 17 Nov 2011 19:20:05 +0800

Mark and Alexandre
Thank you for publishing this document.
When I discuss about 6rd deployment with operators,"sunsetting" is also often considered.
I had 2 idea,
1.change transport to IPv6 "sunsetting"
2.use private IPv4 compression address  with multiple 6rd domains "survival"

But "survival" is not healthy,so I think this "sunsetting" draft would be useful for operators.

And I have comments about section 5.
http://tools.ietf.org/html/draft-townsley-v6ops-6rd-sunsetting-00#section-5
 2.  CEs reachable by Native IPv6 are configured via DHCPv6-PD
       [RFC3633] with the same delegated prefix calculated and in use by
       6rd.
If 6rd delegated prefix could copy to DHCPv6-PD OPTION_IAPREFIX (26) in solicit,it is easy.
http://tools.ietf.org/html/rfc3633#section-10

Regards,
-Shishio

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Nov 2011 15:53:17 -0600

From: Fred Baker (fred) 
Sent: Thursday, November 17, 2011 5:04 PM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); Hans Liu; Alexandre Cassen; [email-masked];
Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>Personally, I'd be a bit perplexed at putting native and 6rd deployment
into the same prefix. I could imagine adjacent prefixes - one is
2001:dba:2:2::/64 and the other >is 2001:dba:2:3::/64. 

The text sent out earlier said a route metric that prefers native IPv6
over 6rd will forward packets for your example above.

Hemant

---

From: Tina TSOU <[email-masked]>
Date: Fri, 18 Nov 2011 01:08:01 +0000

In Section 5, I have doubts in the steps an operator would employ:

1.   In 6rd CE is configured with Ipv6 Prefix for eg: 2001:D000::/20 and not delegated prefix, delegated prefix is calculated with the WAN address of the CE.

2.   What are native and 6rd interfaces? A CE has a LAN interface, a WAN interface and a tunnel interface. For native Ipv6, is the CE connected to the WAN with another interface?

3.   Currently the IP forwarding rule is something like this:

Ipv6 route 2001:D000::/20  tunnel0 ( all 6rd traffic will be forwarded from tunnel interface)

Ipv6 route ::/0 tunnel0  BR-interface(default route for  native v6 traffic from tunnel but via BR)

How will the forwarding rule be with native IPv6? Can you give an example?

4.   If we use the same 6rd prefix for native nodes, BR still has the rule that it forwards only those incoming packets which have this prefix, otherwise discard. But how does BR distinguish whether the packet with this prefix will follow native ipv6 routing or be tunneled? ( As per my understanding with native Ipv6 deployment we also mean that we have some native v6 routing in the n/w for v6 only nodes, though initially there will be very routes and gradually as the n/w changes towards native v6, we want 6rd traffic to become less)

Tina
Sent from my iPad

On Nov 18, 2011, at 5:53 AM, "Hemant Singh (shemant)" <[email-masked]<mailto:[email-masked]>> wrote:

From: Fred Baker (fred)
Sent: Thursday, November 17, 2011 5:04 PM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); Hans Liu; Alexandre Cassen; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>Personally, I'd be a bit perplexed at putting native and 6rd deployment into the same prefix. I could imagine adjacent prefixes - one is 2001:dba:2:2::/64 and the other >is 2001:dba:2:3::/64.

The text sent out earlier said a route metric that prefers native IPv6 over 6rd will forward packets for your example above.

Hemant

---

From: Fred Baker <[email-masked]>
Date: Fri, 18 Nov 2011 09:29:11 +0800

On Nov 18, 2011, at 5:53 AM, Hemant Singh (shemant) wrote:
> Cc: Hemant Singh (shemant); Hans Liu; Alexandre Cassen; [email-masked]; Claire Cheng

Well, yes, but only if the routing protocol in question is set up in a way that routing protocols recognize. I realize that MIF thinks it would be nice to have systems on multiple interfaces using the same prefix. Routing protocols (RIPng, OSPFv3, IS-IS, ...) will want to treat separate prefixes as separate interfaces and single prefixes as single interfaces, or will want to talk about neighbor relationships - the way to get to a set of 6rd prefixes is via a 6rd neighbor, and the way to get to a more general prefix is a different routing neighbor.

Instead of mandating weird route selection rules, it would be really nice to be able to discuss it in terms the routing protocol, and therefore the metric you refer to, which is carried in a routing protocol, understand. 

BTW, this is probably the first time I have heard discussion of a routing protocol exchanged between a broadband ISP and a residential customer that wasn't immediately shouted down by the broadband operator...

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Nov 2011 19:48:18 -0600

-----Original Message-----
From: Fred Baker (fred) 
Sent: Friday, November 18, 2011 9:29 AM
To: Hemant Singh (shemant)
Cc: STARK, BARBARA H; Hans Liu; Alexandre Cassen; [email-masked]; Claire
Cheng

>Well, yes, but only if the routing protocol in question is set up in a
way that routing protocols recognize. I realize that MIF thinks it
>would be nice to have systems on multiple interfaces using the same
prefix. Routing protocols (RIPng, OSPFv3, IS-IS, ...) will want to
>treat separate prefixes as separate interfaces and single prefixes as
single interfaces, or will want to talk about neighbor >relationships -
the way to get to a set of 6rd prefixes is via a 6rd neighbor, and the
way to get to a more general prefix is a different >routing neighbor.

RFC 6204 nor rfc6204bis recommend to not run a routing protocol between
the CPE WAN and the SP.  Neither does rfc6204 support a multihoming
feature (MIF) on the WAN that is needed when the WAN includes at least
two interfaces.  When rfc6204bis mentions a routing metric, it is simply
an auto-created static IPv6 route internal to the CPE router.  Also the
LAN routing protocols in rfc6204bis has been taken out and move to
homenet.  

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Nov 2011 20:07:18 -0600

Fred,

Sorry, there is MIF involved with 6rd and native IPv6 running
concurrently.  However, the auto-generated static route text emailed
below still works.  Soon as native IPv6 is active on the CPE when 6rd
was running previously, the 6rd tunnel will be given lower priority than
native IPv6 for data forwarding.

Hemant

-----Original Message-----
Sent: Friday, November 18, 2011 9:48 AM
To: Fred Baker (fred)

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 18 Nov 2011 10:50:19 +0100

Submitted some Q on this earlier, but no response so far (or I must have missed it, in this case I already apologize).

This draft sets some extra reqs for the CPE.
One of them is that the CPE must be able to cope with receiving the same prefix through 6rd config and native.  So, the CPE RA Daemon will get the same prefix through 2 channels.  The RA daemon sees the prefix twice, but as it is the same, what should the CPE do with the lifetime.
There's only 1 prefix to send to the hosts, so what lifetimes to use/how to update the RA sending ? The most recent ones received ?  native preference over 6rd ?  ... ?

tx

Carl Wuyts

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: vrijdag 18 november 2011 3:07
To: Hemant Singh (shemant); Fred Baker (fred)
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

Fred,

Sorry, there is MIF involved with 6rd and native IPv6 running concurrently.  However, the auto-generated static route text emailed below still works.  Soon as native IPv6 is active on the CPE when 6rd was running previously, the 6rd tunnel will be given lower priority than native IPv6 for data forwarding.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Friday, November 18, 2011 9:48 AM
To: Fred Baker (fred)
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

RFC 6204 nor rfc6204bis recommend to not run a routing protocol between the CPE WAN and the SP.  Neither does rfc6204 support a multihoming feature (MIF) on the WAN that is needed when the WAN includes at least two interfaces.  When rfc6204bis mentions a routing metric, it is simply an auto-created static IPv6 route internal to the CPE router.  Also the LAN routing protocols in rfc6204bis has been taken out and move to homenet.

---

From: Ole Troan <[email-masked]>
Date: Fri, 18 Nov 2011 14:34:22 +0100

Carl,

> There's only 1 prefix to send to the hosts, so what lifetimes to use/how to update the RA sending ? The most recent ones received ?  native preference over 6rd ?  ... ?

you'll get one prefix from 6rd (inherits the IPv4 lease time) and one prefix from DHCP PD.
the correct answer must be the longest of the two.

cheers,
Ole

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 18 Nov 2011 14:39:53 +0100

OK, so probably something to add to the draft then, if not, you might see different approaches I guess.

tx

Carl Wuyts

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: vrijdag 18 november 2011 14:34
To: Wuyts Carl
Cc: Hemant Singh (shemant); Fred Baker (fred); Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

Carl,

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Nov 2011 19:41:00 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Francis Dupont
Sent: Tuesday, November 15, 2011 3:56 AM
To: Mark Townsley
Cc: Alexandre Cassen; [email-masked] WG; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>by an ISP? and IMHO the answer is in general no.

Use case already described in rfc6204bis.  See last paragraph of section
4.4.3 in

http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02

Also see the same use case I replied to in

http://www.ietf.org/mail-archive/web/v6ops/current/msg10718.html

The summary is that even when the Preferred Lifetime is sent as zero to
a node, the prefix lingers for two hours or less and thus 6rd and native
IPv6 coexist concurrently on the CE router.

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Nov 2011 14:50:47 +0900

On Thu, Nov 17, 2011 at 14:29, STARK, BARBARA H <[email-masked]> wrote:

> not have fully covered the case (in 6204bis) where the same prefix is used
> for 6rd and native. In this case, the philosophy of “route based on source
> address” won’t work, and we should probably use the “metric” approach
> proposed by the 6rd sunsetting draft. We also can’t unprefer and invalidate
> the prefix to the LAN.
>

Why do you need to route based on source address? If it's the same ISP
moving its users from 6rd to native, I would assume that it doesn't matter
whether the CPE sends packets out the native interface or the 6rd
interface, since they'll both be accepted by the ISP.

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 22 Nov 2011 01:49:38 -0500

> interface, since they'll both be accepted by the ISP.

Depending if RPF is running on the network, the operator may need/want to
have the outgoing traffic leave a given interface (i.e. if strict mode RFP
running on either the upstream router at the BR or the gateway north of the
native CE path).

Although even in this case, not sure way SBR is needed - metric should be
ok there.

Now my 2 cents....

All that said, I not sure why I would leave both on in the first place.
The complexity of having two paths for the same prefix seems a bit much.
Once I have a native path, I would break the 6RD path (in my operational
environment). Sure the transitioned customer may need to go via a BR to
talk to other 6RD endpoints, but not sure if this traffic volume is that
big of a deal.

Most traffic is to/from the Internet, Caches, CDNs.

regards,

Victor

---

From: Mark Townsley <[email-masked]>
Date: Tue, 22 Nov 2011 10:25:50 +0100

On Nov 22, 2011, at 6:50 AM, Lorenzo Colitti wrote:

> Why do you need to route based on source address? If it's the same ISP moving its users from 6rd to native, I would assume that it doesn't matter whether the CPE sends packets out the native interface or the 6rd interface, since they'll both be accepted by the ISP.

That's certainly the idea in the "same delegated prefix" case. In the "separate prefix" case, they *could* be separate ISPs (particularly when manually configuring 6rd, but that may be out of scope here). 

Just trying to keep things simple here. The CPE brings up 6rd, or not, when told and passes on its prefix, whatever it is. Native does the same.  Forwarding rules prefer native over virtual when the installed routes are identical. That's really the crux of it. With this, the ISP can choose to "flash-cut" or steadily move users to a separate prefix, or keep them on the same prefix for the time being. It's really in the hands of the ISP to decide as long as the CPE can remain simple and deterministic in its response. 

- Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Nov 2011 18:34:15 +0900

On Tue, Nov 22, 2011 at 18:25, Mark Townsley <[email-masked]> wrote:

> That's certainly the idea in the "same delegated prefix" case. In the
> "separate prefix" case, they *could* be separate ISPs (particularly when
> manually configuring 6rd, but that may be out of scope here).
>

If you want to support 6rd service being provided by a different ISP than
native IPv6 service you may have to deal with ingress filtering issues. If
you choose to do so on the CE router, that will complicate the
implementation because it requires the CE router to do source-based routing.

I think doing this in the CE router is a bad idea because it complicates
the implementation all the time for a scenario (different 6rd ISP vs.
native ISP) that is essentially an edge case. Since edge cases tend to be
hard to test for, the CE router implementations might not get it right all
the time, and if even if just a few of them don't get it right, you're now
dropping customer traffic so you're basically forced to relax the ingress
filtering anyway.

I think we should make the CE router assume that if it is simultaneously
provisioned with 6rd and native it should not do policy routing and place
the burden of getting ingress filtering right on ISP/ISPs that is/are
providing the connectivity. After all, if I'm an ISP and use the 6rd
connectivity from another ISP, that ISP will know I'm a customer of theirs.

---

From: Mark Townsley <[email-masked]>
Date: Tue, 22 Nov 2011 10:35:01 +0100

On Nov 22, 2011, at 7:49 AM, Victor Kuarsingh wrote:

> 
> 
> On Tue, Nov 22, 2011 at 12:50 AM, Lorenzo Colitti <[email-masked]> wrote:
> Depending if RPF is running on the network, the operator may need/want to have the outgoing traffic leave a given interface (i.e. if strict mode RFP running on either the upstream router at the BR or the gateway north of the native CE path).

Yes, that's something you might have to worry about if two separate prefixes are being used during a staged cutover from 6rd to native. Just like bringing up any second interface and then tearing down the first. 

> 
> Although even in this case, not sure way SBR is needed - metric should be ok there.
> 
> Now my 2 cents....
> 
> All that said, I not sure why I would leave both on in the first place.  The complexity of having two paths for the same prefix seems a bit much.  Once I have a native path, I would break the 6RD path (in my operational environment). Sure the transitioned customer may need to go via a BR to talk to other 6RD endpoints, but not sure if this traffic volume is that big of a deal.

That's certainly an option. You MUST renumber the user to a new prefix outside the 6rd domain in this case of course. So, this is either immediate or staged, and if staged you have to deal with the "multihomed" 6rd+native case for at least a period of time. The most apparent to the user of course is a "flash-cut", but if that's not a problem, then it might be the easiest way to go for you. 

I'm just trying to keep the CPE simple, and the choice of migration in the hands of the operator here. 

> Most traffic is to/from the Internet, Caches, CDNs.

(and CGNs...? :-)

You might find once the end-to-end Internet is returned with v6 you might have less centralization in the network ;-) 

I agree though, depending on the network the added CE-CE traffic through the BRs may not be significant. Again, just trying to give you the options...

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Tue, 22 Nov 2011 10:54:06 +0100

On Nov 22, 2011, at 10:34 AM, Lorenzo Colitti wrote:

> If you want to support 6rd service being provided by a different ISP than native IPv6 service you may have to deal with ingress filtering issues. If you choose to do so on the CE router, that will complicate the implementation because it requires the CE router to do source-based routing.
> 
> I think doing this in the CE router is a bad idea because it complicates the implementation all the time for a scenario (different 6rd ISP vs. native ISP) that is essentially an edge case. Since edge cases tend to be hard to test for, the CE router implementations might not get it right all the time, and if even if just a few of them don't get it right, you're now dropping customer traffic so you're basically forced to relax the ingress filtering anyway.

Perhaps there is room for a "conservative in what you send" and "liberal in what you accept" bit of advice here. 

> 
> I think we should make the CE router assume that if it is simultaneously provisioned with 6rd and native it should not do policy routing and place the burden of getting ingress filtering right on ISP/ISPs that is/are providing the connectivity. After all, if I'm an ISP and use the 6rd connectivity from another ISP, that ISP will know I'm a customer of theirs.

For a CE that is only capable of supporting one ISP on its native interfaces anyway, I agree. And, the case I mentioned above where 6rd terminates outside the ISP for which v4 is served, you are likely in "manual config" territory anyway, and all bets are off. I don't think we need to specify how much control the CE does or does not give here once the config is exposed to the user.  

I think it might get more complicated as you introduce CE that can multihome to different ISPs in general. But, here you have introduced and will be reliant upon source routing anyway.

- Mark

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 22 Nov 2011 11:22:50 +0100

+1, indeed nothing to be pushed to the CPE side.

Carl Wuyts

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: dinsdag 22 november 2011 10:34
To: Mark Townsley
Cc: Claire Cheng; [email-masked]; Alexandre Cassen
Subject: Re: [v6ops] 6rd Sunsetting

On Tue, Nov 22, 2011 at 18:25, Mark Townsley <[email-masked]<mailto:[email-masked]>> wrote:
Why do you need to route based on source address? If it's the same ISP moving its users from 6rd to native, I would assume that it doesn't matter whether the CPE sends packets out the native interface or the 6rd interface, since they'll both be accepted by the ISP.

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Nov 2011 14:36:12 +0100

Hi,

On Tue, Nov 22, 2011 at 06:34:15PM +0900, Lorenzo Colitti wrote:
> native IPv6 service you may have to deal with ingress filtering issues. 

Even if it's the same ISP, it's two different machineries that terminate
6rd and "native", and neither might have knowledge about "the other" prefix.

So if "straightforward" BCP38 filtering is used, I'd expect this to drop
packets arriving over the "wrong" technology.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

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: Mark Townsley <[email-masked]>
Date: Tue, 22 Nov 2011 15:43:58 +0100

> packets arriving over the "wrong" technology.

The 6rd BR would drop traffic that didn't have a matching IPv4 and IPv6-mapped source address as well. So, traffic from a Native Prefix source isn't going to get far after reaching the end of the tunnel unless there is a way to configure an exception to the 6rd source mapping check. Assuming that is even possible, now you have introduced a spoofing security issue that you probably didn't want to have, or a ton of state if you try to do this per-site. 

At its base, 6rd + native with two separate prefixes ends up looking a lot like regular multihoming. It's one reason why, after Alexandre and I walked through the various implications, thought that the "single prefix" mode had value for an operator (not to mention the user not having to live through a renumbering event) . 

I'm beginning to think that in the separate prefix mode the CE is going to have to be able to do source routing to the two interfaces. The only alternatives are dropping traffic, rebooting the entire home, or getting liberal in your source address checks in the network. To Lorenzo's point, the CE might "get it wrong" just like it might steer packets the wrong way over two native interfaces. With 6rd + native the ISP has the opportunity to say "well, OK, these are all from my users, I'll let it pass" but it may not be easy to do that without a fairly serious relaxation of security policy....

- Mark

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 22 Nov 2011 09:51:28 -0500

Le 2011-11-22 à 09:43, Mark Townsley a écrit :

> I'm beginning to think that in the separate prefix mode the CE is going to have to be able to do source routing to the two interfaces.

I think that (source routing) is the only way to do it right.

Marc.

> The only alternatives are dropping traffic, rebooting the entire home, or getting liberal in your source address checks in the network. To Lorenzo's point, the CE might "get it wrong" just like it might steer packets the wrong way over two native interfaces. With 6rd + native the ISP has the opportunity to say "well, OK, these are all from my users, I'll let it pass" but it may not be easy to do that without a fairly serious relaxation of security policy....
> 
> - Mark
> 
>> 
>> Gert Doering
>>       -- NetMaster
>> --

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Nov 2011 10:14:49 +1300

>> native IPv6 service you may have to deal with ingress filtering issues. 

I don't understand why a second ISP would be involved; the
process being documented is how a single ISP moves its customers
over from 6rd.

> packets arriving over the "wrong" technology.

This, or strict RPF, would be self-foot-shooting by the ISP
wishing to sunset 6rd. It seems fairly simple to specify that
both ingress filtering and RPF should be configured to allow
both prefixes simultaneously. This is a standard need for
multihomed PA customers anyway, and needs to become standard
practice for all IPv6 ISPs.

While we do need a solution for source-prefix based exit
selection, we don't have one yet and it's a separable problem.

    Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Nov 2011 16:09:48 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marc Blanchet
Sent: Tuesday, November 22, 2011 9:51 AM
To: Mark Townsley
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>I think that (source routing) is the only way to do it right.

Before even the townsley document was out, the ipv6 cpe router design
team in the -02 version of the document had already specified source
based switching in the CE if 6rd and native IPv6 use different prefixes.
In our design mailer we had also specified in earlier text before -02
was released to prefer native IPv6 over 6rd when both are active and
using the same prefix but we thought this was an obvious case and didn't
add text for the case in the -02 version.  However seeing that the same
prefix case is preferred by the community to specify, we added the text
for even this case to the -03 version.  This is bullet 5 from section
4.4.3 of 

http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-03

[5.  Selection of 6rd tunnel or native IPv6 output interface on the CE

       native IPv6.  If the two interfaces provide the CE router with

       the same prefix, then the CE router prefers the native IPv6

       interface to the 6rd interface for forwarding traffic out the WAN

       when both 6rd and native IPv6 interfaces are active.]

Please also read the whole section of 4.4.3.

Thanks and regards,

Hemant

---

From: Gert Doering <[email-masked]>
Date: Wed, 23 Nov 2011 09:01:13 +0100

Hi,

On Wed, Nov 23, 2011 at 10:14:49AM +1300, Brian E Carpenter wrote:
> both prefixes simultaneously. 

Permit me a polite cough here.

*The* benefit of 6rd on the gateway side is that it's stateless, which
means "no per-subscriber information needs to be gathered, kept, and
validated for incoming packets".

So either you want RPF filtering on the 6rd side, or not - but there is
no reasonable way you can ISP subscriber data for a reasonable-sized
ISP into the 6rd gateways to enable RPF filtering "plus extra prefixes
for some of the subscribers" on the 6rd gateway.

> This is a standard need for

This is a standard *problem*, not a "standard need".

You're not going to see large-scale ISPs that do deploy RPF filtering
(few enough, alas) add "oh, this customer also has prefix X from ISP Z
this week!" to their subscriber management platform, which is where the 
routers get configured from.  Including verification that this 
customer is even entitled to *use* prefix X at this time.

> selection, we don't have one yet and it's a separable problem.

I strongly disagree.  This is the core of the problem for multi-PA-based
multihoming, and one variant presents itself now with "two different
access technologies with different prefixes to the same ISP".

Gert Doering
        -- NetMaster

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Nov 2011 04:53:50 -0600

From: [email-masked] [mailto:[email-masked]] On Behalf
Of STARK, BARBARA H
Sent: Tuesday, November 15, 2011 10:33 AM
To: [email-masked]
Subject: Re: [v6ops] 6rd Sunsetting

>But when the CE router was manually configured for 6rd, I have no clue
what this means. How is the manually-configured CE router supposed to
know whether or not 6rd is configured by >the SP? Some guidance in this
area would be appreciated. For example, should the CE router test to see
if the BR is reachable, and if not assume that 6rd is not configured by
the SP?

How can a subscriber in the home manually configure the CE router for
four 6rd parameters including the IPv4 address of the BR unless the
subscriber called the SP and got the information to configure manually.
Thus the SP knows about the CPE router in the subscriber's home and also
the CE router does not need to test if 6rd is configured by the SP.  If
the CE router still wants to test, then use the NUD specified in section
8 of RFC 5969.

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Wed, 23 Nov 2011 14:30:53 +0100

I think that manually configured 6rd, or manually configured anything really, should be squarely out of scope whenever possible. I think the WG should focus on default behavior and configuration handled via our protocols. Once you've opened a user-level interface, all bets are off. 

That said, a manually configured 6rd interface should not be difficult as long as you don't try to treat it "special". It's just another interface like any other on the router. It has its own entry in the forwarding table, and rules that are consistent with what we should define for an ISP-configured 6rd interface. Everything we have discussed here in terms of what is in 6rd-sunsetting and source routing to the correct interface apply perfectly well, even if you have manual and SP-configured interfaces (not to mention an HE tunnel on the side, etc.)

The hard part comes when the CPE tries to become too intelligent for its own good, automatically preferring one type of interface configuration over another (note that I didn't say preferring one *route* over another when the entries in the forwarding table are otherwise equal, I said preferring one type of *configuration* over the other). I think this is inherently bad as it means every single time there is a new type of interface (virtual or otherwise) you have to fit it into a logic table of what is and is not allowed. As long as the router can handle multiple interfaces generically, it should "do as it's told", bring up interfaces it has SP-supported or explicit manual configuration for, and route accordingly.  

For troubleshooting, RFC 5969 includes advice on how to construct a packet that will not only test the path between the CE and BR, it will tell you which BR that packet happened to traverse. One could run a BFD-like keepalive on a timer on the 6rd tunnel (the "NUD" section Hemant refers to), but I think that's overkill for 6rd as long as you have a well-supported BR deployment to plug into. If you are using the 6rd config with a single BR that is not well-supported, you might want the CE to declare the interface down when a periodic NUD check fails. It should be clear though that this is far removed from a "production" ISP-supported 6rd deployment, and much more of a "trial" type of operation that I think 6204-bis should not have to worry about. 

- Mark

On Nov 23, 2011, at 11:53 AM, Hemant Singh (shemant) wrote:

>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
> >But when the CE router was manually configured for 6rd, I have no clue what this means. How is the manually-configured CE router supposed to know whether or not 6rd is configured by >the SP? Some guidance in this area would be appreciated. For example, should the CE router test to see if the BR is reachable, and if not assume that 6rd is not configured by the SP?
>  
> How can a subscriber in the home manually configure the CE router for four 6rd parameters including the IPv4 address of the BR unless the subscriber called the SP and got the information to configure manually.  Thus the SP knows about the CPE router in the subscriber’s home and also the CE router does not need to test if 6rd is configured by the SP.  If the CE router still wants to test, then use the NUD specified in section 8 of RFC 5969.
>  
> Hemant

---

From: Mark Townsley <[email-masked]>
Date: Wed, 23 Nov 2011 15:45:27 +0100

In practice, source address checking is done, per-subscriber, at the first L3 hop (BNG, CMTS, etc.) or before (DSLAM, Access Node, etc.).

6rd tunnels over this part of the network. As long as the IPv6 source and IPv4 source are bound, this isn't a problem, as the address checking is being done for IPv4 on a per-subscriber basis, and the BR does a (stateless) check on decap to ensure that the IPv6 source and IPv4 source match.  

If you introduce an IPv6 packet with a different source address into the 6rd tunnel and expect it not to be dropped, you are really no longer doing 6rd. Without the mapping to rely on, you have to either choose between decapsulating any packet that arrives (and the associated spoofing implications), or configure ACLs at pick-your-favorite-aggregation-level from the entire ISP down to a single subscriber where you are then essentially importing all the state from the first hop(s) into the BR. 

So, I think Gert's right here. For all practical purposes, when a 6rd and native interface are up with different prefixes for each, the CPE has to ensure that it sends packets over the right interface. Same is true for multihoming in general. Only way to get around it is to keep the prefix the same. 

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Nov 2011 09:42:29 -0600

Mark,

Thanks.  I agree.  Barbara,  based on Mark's reply, do we still need
manual configuration for 6rd in rfc6204bis and if so, what more for
guidance would you like?

Hemant

From: Mark Townsley [mailto:[email-masked]] 
Sent: Wednesday, November 23, 2011 8:31 AM
To: Hemant Singh (shemant)
Cc: STARK, BARBARA H; [email-masked]
Subject: Re: [v6ops] 6rd Sunsetting

I think that manually configured 6rd, or manually configured anything
really, should be squarely out of scope whenever possible. I think the
WG should focus on default behavior and configuration handled via our
protocols. Once you've opened a user-level interface, all bets are off. 

That said, a manually configured 6rd interface should not be difficult
as long as you don't try to treat it "special". It's just another
interface like any other on the router. It has its own entry in the
forwarding table, and rules that are consistent with what we should
define for an ISP-configured 6rd interface. Everything we have discussed
here in terms of what is in 6rd-sunsetting and source routing to the
correct interface apply perfectly well, even if you have manual and
SP-configured interfaces (not to mention an HE tunnel on the side, etc.)

The hard part comes when the CPE tries to become too intelligent for its
own good, automatically preferring one type of interface configuration
over another (note that I didn't say preferring one *route* over another
when the entries in the forwarding table are otherwise equal, I said
preferring one type of *configuration* over the other). I think this is
inherently bad as it means every single time there is a new type of
interface (virtual or otherwise) you have to fit it into a logic table
of what is and is not allowed. As long as the router can handle multiple
interfaces generically, it should "do as it's told", bring up interfaces
it has SP-supported or explicit manual configuration for, and route
accordingly.  

For troubleshooting, RFC 5969 includes advice on how to construct a
packet that will not only test the path between the CE and BR, it will
tell you which BR that packet happened to traverse. One could run a
BFD-like keepalive on a timer on the 6rd tunnel (the "NUD" section
Hemant refers to), but I think that's overkill for 6rd as long as you
have a well-supported BR deployment to plug into. If you are using the
6rd config with a single BR that is not well-supported, you might want
the CE to declare the interface down when a periodic NUD check fails. It
should be clear though that this is far removed from a "production"
ISP-supported 6rd deployment, and much more of a "trial" type of
operation that I think 6204-bis should not have to worry about. 

- Mark

 

 

Hemant

---

From: Wes Beebee <[email-masked]>
Date: Wed, 23 Nov 2011 14:37:44 -0500

> So, I think Gert's right here. For all practical purposes, when a 6rd and
> native interface are up with different prefixes for each, the CPE has to
> ensure that it sends packets over the right interface. Same is true for
> multihoming in general. Only way to get around it is to keep the prefix the
> same. 

Section 4.4.3 of draft-ietf-v6ops-6204bis-03:

"  5.  Selection of 6rd tunnel or native IPv6 output interface on the CE
       router is determined by the source IPv6 address of the packet
       from a host, when different prefixes are available over 6rd vs.
       native IPv6.  If the two interfaces provide the CE router with
       the same prefix, then the CE router prefers the native IPv6
       interface to the 6rd interface for forwarding traffic out the WAN
       when both 6rd and native IPv6 interfaces are active.

   6.  The CE router messages to the host the use of native IPv6 in
       preference to 6rd, in the case where the two interfaces use
       different prefixes."

- Wes

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Nov 2011 09:23:08 +1300

Gert,

> for some of the subscribers" on the 6rd gateway.

I would not propose doing it per-subscriber, for exactly that reason.
During the sunset procedure, you would have to allow a prefix short enough to
cover all subscribers. Yes, that might mean relaxing your anti-spoofing
during the sunset. That's a trade-off.

> customer is even entitled to *use* prefix X at this time.

It needs to be automated, and that's a protocol gap (which v6ops
by construction cannot fix). It will also end up as part of the
6renum gap analysis.

> access technologies with different prefixes to the same ISP".

Actually we agree - it is a core problem here, for 6renum, and for
ipv6-multihoming-without-ipv6nat. Probably for MIF and HOMENET too.
That's all I meant by saying it's separable: we need to solve the
general case.

   Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Nov 2011 14:26:53 -0600

Clarifying question:

By 6rd on the gateway side, do we mean the gateway is the 6rd BR (Border
Relay) or the home gateway in the CPE router?  Sorry, I haven't caught
up with all emails on this thread yet,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian E Carpenter
Sent: Wednesday, November 23, 2011 3:23 PM
To: Gert Doering
Cc: Alexandre Cassen; Claire Cheng; [email-masked]
Subject: Re: [v6ops] 6rd Sunsetting

Gert,

I would not propose doing it per-subscriber, for exactly that reason.
During the sunset procedure, you would have to allow a prefix short
enough to
cover all subscribers. Yes, that might mean relaxing your anti-spoofing
during the sunset. That's a trade-off.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Nov 2011 09:28:02 +1300

>        preference to 6rd, in the case where the two interfaces use

I am not sure I understand how rule 5 is implemented algorithmically.
Can you spell it out?

    Brian

---

From: Wes Beebee <[email-masked]>
Date: Wed, 23 Nov 2011 15:40:26 -0500

> I am not sure I understand how rule 5 is implemented algorithmically.

One possible implementation of rule 5 (e.g. On Cisco routers) would be
Policy-Based Routing (PBR) selecting by an Access Control List (ACL)
matching the source IPv6 address to the native or 6rd prefix (when
different), that would then select the output interface as the PBR action.
When the prefixes are configured to be the same, two routes would be
configured in the Forwarding Information Base (FIB) for native and 6rd and
the native route would have a lower administrative distance metric than the
6rd route.

It's possible to configure this on a Cisco router such that the behavior
described in #5 is observed.  However, for a super cheap home router, they
may not choose to actually implement all of PBR, ACL, etc - and they may
find a more direct way to implement the behavior described in #5.

- Wes

---

From: Tina TSOU <[email-masked]>
Date: Wed, 23 Nov 2011 22:49:13 +0000

Wes,
Would you show some examples of command line of 6rd Sunsetting configuration on BR and CE?

-Tina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wes Beebee
Sent: Wednesday, November 23, 2011 12:40 PM
To: Brian E Carpenter
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

- Wes

---

From: Mark Townsley <[email-masked]>
Date: Thu, 24 Nov 2011 00:10:35 +0100

>       when both 6rd and native IPv6 interfaces are active.

This sounds about right. I think we should be more explicit about the "when" and "active" part in the last line though, as that's the crux of the issue around what to do when receiving configuration for 6rd and native interfaces on the same router. If the router shuts off 6rd prematurely (IMHO, before the ISP says its OK by no longer providing config), then it risks blackholing traffic from other CEs.  

>       preference to 6rd, in the case where the two interfaces use

I'd be more comfortable with 6rd simply falling in line with general advice on multihoming with multiple prefixes. It's really the same case. 

Homenet Chair Nit: By specifying what should happen with routers and hosts on the LAN side, we're dipping a bit into homenet territory. As long as it's consistent with what homenet ends up with, no harm no foul, but I'd hate to jump the gun. 

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Nov 2011 15:35:23 +1300

> find a more direct way to implement the behavior described in #5.

They'd better. We've been trying to get rules like this set up in our Uni's
border routers, so that we can run some real-world shim6 tests using alternative
paths between two prefixes on our campus (in NZ) and two prefixes on another
campus Somewhere in Europe. Getting it right even for a static test setup is
proving frustrating and quite hard to explain to the operational folk. In a
small enterprise or homenet context it *must* be automatic.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Nov 2011 12:07:10 +0900

On Tue, Nov 22, 2011 at 23:43, Mark Townsley <[email-masked]> wrote:

> I'm beginning to think that in the separate prefix mode the CE is going to
> have to be able to do source routing to the two interfaces.
>

If the native network drops traffic with 6rd source addresses, and the 6rd
BR drops traffic with native source addresses, then the only way to have
things work is either to use the same prefix or to have the CE not send the
traffic the wrong way.

I do stand by my assertion that relying on the CE router to get this right
all the time is a risky bet and is unlikely to work in all cases unless the
ISP manages the CE (in which case of course they can do what they like
anyway).

---

From: Mark Townsley <[email-masked]>
Date: Thu, 24 Nov 2011 08:43:03 +0100

On Nov 24, 2011, at 4:07 AM, Lorenzo Colitti wrote:

> If the native network drops traffic with 6rd source addresses, and the 6rd BR drops traffic with native source addresses, then the only way to have things work is either to use the same prefix or to have the CE not send the traffic the wrong way.

Right. And this is one of the reasons, after thinking it through, the single prefix option had some attractive characteristics. It lets you avoid source routing and RPF issues, as well as not renumbering the user and gives you optimal paths in terms of BR traversal to boot.  

> 
> I do stand by my assertion that relying on the CE router to get this right all the time is a risky bet and is unlikely to work in all cases unless the ISP manages the CE (in which case of course they can do what they like anyway).

A statement that really should apply to the generic multihoming case as well as the 6rd one. 

- Mark

---

From: Gert Doering <[email-masked]>
Date: Thu, 24 Nov 2011 10:07:12 +0100

Hi,

> That's all I meant by saying it's separable: we need to solve the

With that explanation, yes, I can agree - it's a more general problem,
which, when solved, will catch this particular case as well.

Gert Doering
        -- NetMaster

---

From: Mark Townsley <[email-masked]>
Date: Thu, 24 Nov 2011 10:10:53 +0100

> which, when solved, will catch this particular case as well.

+1

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 24 Nov 2011 15:02:19 -0600

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lorenzo Colitti
Sent: Wednesday, November 23, 2011 10:07 PM
To: Mark Townsley
Cc: Claire Cheng; [email-masked]; Alexandre Cassen
Subject: Re: [v6ops] 6rd Sunsetting

>If the native network drops traffic with 6rd source addresses,

Which network segment are we talking about?  In the network between the
CE router and the 6rd BR, the BR controls the phasing out of 6rd and
hence the BR is likely not to drop 6rd sourced traffic.   If the network
segment is north of the BR why would the network drop an IPv6 packet of
the 6rd prefix?  If the CE router is directly communicating to another
CE router,  we have 6rd traffic that the receiving CE router does not
drop.  Anyhow, don't drop without sending an ICMPv6 Destination
Unreachable error message to the source.  

>and the 6rd BR drops traffic with native source addresses,

It is the BR who indicated to the CE router via an RA that native IPv6
is available and say, the CE router acquired a new prefix (different
from the 6rd prefix).  So why would the BR drop native IPv6 sourced
traffic if the rfc6204bis, rule 5 in section 4.4.3 is applied?

>I do stand by my assertion that relying on the CE router to get this
right all the time is a risky bet and is unlikely to work in all cases
unless the ISP manages the CE (in which >case of course they can do what
they like anyway).

MarkT has already said, "manual 6rd configuration is out of scope of the
6rd and 6rd sunsetting specification.

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Fri, 25 Nov 2011 07:08:21 +0100

On Nov 24, 2011, at 10:02 PM, Hemant Singh (shemant) wrote:

> Which network segment are we talking about?  In the network between the CE router and the 6rd BR, the BR controls the phasing out of 6rd and hence the BR is likely not to drop 6rd sourced traffic.  

The *native* IPv6 network. No BR in the native IPv6 network. 

> If the network segment is north of the BR why would the network drop an IPv6 packet of the 6rd prefix?  If the CE router is directly communicating to another CE router,  we have 6rd traffic that the receiving CE router does not drop.  Anyhow, don’t drop without sending an ICMPv6 Destination Unreachable error message to the source. 

I think you are confused. Lorenzo is saying that if you send a packet from a subscriber into the native IPv6 network with a source address that does not match a delegated prefix for that subscriber, it is likely to be dropped by the native IPv6 network. 

> It is the BR who indicated to the CE router via an RA that native IPv6 is available and say,

No, BRs do not send RAs to CEs. BRs have no state, and may be multiple L3 hops away from the CE. 

Are you are confusing "BR" and "BNG"?

> the CE router acquired a new prefix (different from the 6rd prefix).  So why would the BR drop native IPv6 sourced traffic if the rfc6204bis, rule 5 in section 4.4.3 is applied?

If the BR receives an IPv6 packet encapsulated in IPv4 and destined to the 6rd tunnel IPv4 destination address, it will perform a check on the source IPv6 and IPv4 addresses to see if they match the configured 6rd rule (see RFC 5969). If they do not match, the packet is dropped. An IPv6 address from outside the 6rd prefix for the 6rd domain will by definition not match. 

>  
> >I do stand by my assertion that relying on the CE router to get this right all the time is a risky bet and is unlikely to work in all cases unless the ISP manages the CE (in which >case of course they can do what they like anyway).
>  
> MarkT has already said, “manual 6rd configuration is out of scope of the 6rd and 6rd sunsetting specification.

That is my point of view, but I don't think Lorenzo is talking about manual config in this sentence.

I think Lorenzo is saying that based on his experience, IPv6 implementations in home routers are not of the highest quality and that anything but the simplest of configurations are not likely to work as expected.

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 25 Nov 2011 10:44:08 -0600

From: Mark Townsley [mailto:[email-masked]] 
Sent: Friday, November 25, 2011 1:08 AM
To: Hemant Singh (shemant)
Cc: Lorenzo Colitti; Claire Cheng; [email-masked]; Alexandre Cassen
Subject: Re: [v6ops] 6rd Sunsetting

>The *native* IPv6 network. No BR in the native IPv6 network. 

It would be good to mention such details.  No further discussion is
possible unless a network topology diagram is presented and then we can
discuss what node sends and what node drops packets.

>I think you are confused.

Given the short text Lorenzo sent out with no diagram one can't even
verify what the problem is.

>Lorenzo is saying that if you send a packet from a subscriber into the
native IPv6 network with a source address that does not match a
delegated prefix for that subscriber, it is >likely to be dropped by the
native IPv6 network. 

The CE router has a 6rd prefix and possibly a native IPv6 different
prefix.  Why are routes for such prefixes not injected in the network
northbound?  That is why a network diagram would be useful for any
further conversation.

>Are you are confusing "BR" and "BNG"?

BNG and BR are co-resident.  Even if they are not, the BNG sends the RA
and the BNG routing propagates new routes for a different prefix in the
northbound BR.   

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 25 Nov 2011 11:48:24 -0600

Mark,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Townsley
Sent: Wednesday, November 23, 2011 6:11 PM
To: Wes Beebee (wbeebee)
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>This sounds about right. I think we should be more explicit about the
"when" and "active" part in the last line though, as that's the >crux of
the issue around what to do when receiving configuration for 6rd and
native interfaces on the same router. If the router shuts >off 6rd
prematurely (IMHO, before the ISP says its OK by no longer providing
config), then it risks blackholing traffic from other CEs.  

Thanks for the review.  In rfc6204bis it was deliberate that bullet 5 in
section 4.4.3 only deals with concurrent operation rules for 6rd and
native IPv6.  How the CE router enters concurrent operation to phase out
6rd is in the subsequent paragraph below the bullets.  The paragraph
assumes 6rd is deprecated immediately on the CE router on acquiring
native IPv6 addressing. This is what Fred Baker also said on the
subject. 

"I think the argument for thinking about routing is to direct traffic to
the wider PMTU when possible and to have native deployment obsolete 6rd
deployment quickly." 

We can discuss if immediate deprecation is not required what does the CE
router do.  The cue has to come from the SP and the townsley 6rd
sunsetting document specifies how the SP cue is signaled.  I have some
thought on the SP cue that I can discuss with you offline and contribute
text to the 6rd sunsetting document.

>I'd be more comfortable with 6rd simply falling in line with general
advice on multihoming with multiple prefixes. It's really the same
>case. 

Totally agree.  That is why we have a simplistic source-based switching
rule in bullet 5 specified for the real cheap CE router.  The general
case of multihoming with different multiple prefixes is solved by PBR
that operates on the source-address bit.  

>Homenet Chair Nit: By specifying what should happen with routers and
hosts on the LAN side, we're dipping a bit into homenet territory. >As
long as it's consistent with what homenet ends up with, no harm no foul,
but I'd hate to jump the gun. 

Agree with being consistent with homenet.  Please note rfc6204 is a
single router WAN and LAN specification and rfc6204bis has continued on
the same path.  Thus rfc6204bis is legal to specify LAN behavior.  Thus
it would be good for the homenet folks to review bullet 6.

Thanks,

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Sat, 26 Nov 2011 02:08:54 +0100

> the wider PMTU when possible and to have native deployment obsolete 6rd

"when possible" and "quickly" != immediately 

> router do.  

I think it is a lot simpler if the router just does what it is told. 

> The cue has to come from the SP and the townsley 6rd

OK. I hope it does not involve changes to RFC 5969 though.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Sun, 27 Nov 2011 13:51:35 +0100

On Nov 25, 2011, at 5:44 PM, Hemant Singh (shemant) wrote:

> It would be good to mention such details.  No further discussion is possible unless a network topology diagram is presented and then we can discuss what node sends and what node drops packets.

Seriously?  Why would a native IPv6 network need a 6rd Border Relay (BR) function. 

> Given the short text Lorenzo sent out with no diagram one can’t even verify what the problem is.
>  
> >Lorenzo is saying that if you send a packet from a subscriber into the native IPv6 network with a source address that does not match a delegated prefix for that subscriber, it is >likely to be dropped by the native IPv6 network. 
>  
> The CE router has a 6rd prefix and possibly a native IPv6 different prefix.  Why are routes for such prefixes not injected in the network northbound? 

Because of the additional overhead of doing so.

> That is why a network diagram would be useful for any further conversation.

> BNG and BR are co-resident. 

Absolutely not. 

The 6rd BR function, whether within the BNG or not (and in today's deployments it typically is not), is entirely separate from the BNG functionality. 

> Even if they are not, the BNG sends the RA and the BNG routing propagates new routes for a different prefix in the northbound BR.  

You could if you wanted to, but that's additional state. 

Still, if a packet arrives over the 6rd tunnel with anything by a 6rd source prefix, the 6rd security check is going to drop the packet. Bypassing this check opens a security hole, and requires lots of state to close it back up properly.

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 27 Nov 2011 11:17:17 -0600

Sent: Sunday, November 27, 2011 7:52 AM

>Absolutely not.

Why is it absolutely not?  What document or technical problems prohibits
one from including the BR in the BNG?  Anyway, if the BR and the BNG are
not co-resident,  what protocol exists between the BR and the BNG to
sunset 6rd?  Which of BR or the BNG signals start of 6rd sunsetting and
then how does the BR/BNG get notified?   If a protocol is not used one
has to use ad hoc means to coordinate the sunsetting between devices in
the SP domain.  Let's specify the ad hoc steps or the protocol.  

Hemant

---

From: Tina TSOU <[email-masked]>
Date: Sun, 27 Nov 2011 18:22:39 +0000

Same questions here.

Sent from my iPad

On Nov 27, 2011, at 7:17 AM, "Hemant Singh (shemant)" <[email-masked]<mailto:[email-masked]>> wrote:

Cc: Lorenzo Colitti; Claire Cheng; [email-masked]<mailto:[email-masked]>; Alexandre Cassen

>Absolutely not.

Why is it absolutely not?  What document or technical problems prohibits one from including the BR in the BNG?  Anyway, if the BR and the BNG are not co-resident,  what protocol exists between the BR and the BNG to sunset 6rd?  Which of BR or the BNG signals start of 6rd sunsetting and then how does the BR/BNG get notified?   If a protocol is not used one has to use ad hoc means to coordinate the sunsetting between devices in the SP domain.  Let’s specify the ad hoc steps or the protocol.

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Sun, 27 Nov 2011 20:46:21 +0100

There is nothing to stop the BR from being the same piece of equipment as the BNG, but the BR function itself described in RFC 5569 or 5969 is not "subscriber aware" by design. The BR and BNG are very much functionally separate. I'll note that the deployment at Free and most of the others I am aware of today, the BR is a separate box not co-located with the BNG. I have seen designs where the plan was to enable BR functionality on the BNG over time, and there is nothing wrong with that. What I am saying here is that it is "absolutely not" *necessary* to make them co-resident.

There is no need for the BR and BNG to communicate directly to sunset 6rd, and certainly no new protocol to invent here. The steps necessary for two methods are outlined in 6rd-sunsetting, and graphically in the presentation I rushed through in v6ops (though the slides should be part of the proceedings). These are guidelines, leading to the more important part: requirements for the CPE. An operator will certainly have its own environment to consider, and may move very quickly or very slowly, with one prefix or more than one, when sunsetting.

The only "ISP to CE" control protocol needed to turn off 6rd is the same needed to turn on 6rd. As described in 6rd-subsetting, If using the "same prefix" method (#2 in the draft and my presentation) the operator can choose to inject routes into the IGP (or configure static routes) to direct downstream traffic towards the native or BR path (when and for what level of aggregate to do this is a choice, it is not necessary for packets to continue to reach the subscriber). If using the "different-prefix" method, then this isn't necessary as 6rd and native together "simply" looks like multihoming with distinct routing for each prefix until 6rd is no longer available on that CE. 

Please don't make this more difficult that it is. All we are doing here is moving the subscriber from one interface type to another. 

- Mark

On Nov 27, 2011, at 7:22 PM, Tina TSOU wrote:

> Same questions here.
> 
> Sent from my iPad
> 
> On Nov 27, 2011, at 7:17 AM, "Hemant Singh (shemant)" <[email-masked]> wrote:
> 
>>  
>>

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 27 Nov 2011 17:10:43 -0500

**  Biased Operator View **

>There is nothing to stop the BR from being the same piece of equipment as the
BNG, but the BR function itself described in >RFC 5569 or 5969 is not
"subscriber aware" by design. The BR and BNG are very much functionally
separate. I'll note that >the deployment at Free and most of the others I am
aware of today, the BR is a separate box not co-located with the BNG. I >have
seen designs where the plan was to enable BR functionality on the BNG over time,
and there is nothing wrong with >that. What I am saying here is that it is
"absolutely not" *necessary* to make them co-resident.

I would say that the likelihood that BNG and BR are co-resident are not
likely in early 6RD deployments (if ever).  If the BR functionality was
built into the BNG maybe, but I am not sure how common that is today.

What ever we do here should not assume this mode of operation (but as noted,
does not preclude it either).  From our point of view, BRs will be planted
in various parts of the network and would be scaled according to load (since
there are other functions that an operator may want to co-locate with the BR
that would need to scale out too).

Even if the BR was co-resident, the return path of the IPv6 flow may be
serviced by a different BR (since the ingress and egress paths need not be
the same).  This would of course be highly dependant on the operators BR and
routing design.

>There is no need for the BR and BNG to communicate directly to sunset 6rd, and
certainly no new protocol to invent here. >The steps necessary for two methods
are outlined in 6rd-sunsetting, and graphically in the presentation I rushed
through in >v6ops (though the slides should be part of the proceedings). These
are guidelines, leading to the more important part: >requirements for the CPE.
An operator will certainly have its own environment to consider, and may move
very quickly or >very slowly, with one prefix or more than one, when sunsetting.

>Please don't make this more difficult that it is. All we are doing here is
moving the subscriber from one interface type to another.

In my opinion, the simpler the requirements on the CPE the better
(especially when it comes to how the CPE interacts with the network).   You
cannot imagine the /fun/ we have with CPE behaviour today in our networks
(coming from all kinds of places and vendors),  I would suggest too much
more complexity on the CPE would exasperate this.

Victor K

On Nov 27, 2011, at 7:22 PM, Tina TSOU wrote:

>> Why is it absolutely not?  What document or technical problems prohibits one
>> from including the BR in the BNG?  Anyway, if the BR and the BNG are not
>> co-resident,  what protocol exists between the BR and the BNG to sunset 6rd?
>> Which of BR or the BNG signals start of 6rd sunsetting and then how does the
>> BR/BNG get notified?   If a protocol is not used one has to use ad hoc means
>> to coordinate the sunsetting between devices in the SP domain.  Let¹s specify
>> the ad hoc steps or the protocol.
>>  
>> Hemant
>>  
>> 
>>  
>>  

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 27 Nov 2011 17:34:39 -0600

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Victor Kuarsingh
Sent: Sunday, November 27, 2011 5:11 PM
To: Mark Townsley; Tina TSOU
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>In my opinion, the simpler the requirements on the CPE the better
(especially when it comes to how the CPE interacts with the network).
You cannot imagine the /fun/ we have with CPE behaviour today in our
networks (coming from all kinds of >places and vendors),  I would
suggest too much more complexity on the CPE would exasperate this.

Agreed.  However, I am not discussing the CPE router.   I am discussing
the SP 6rd and native IPv6 domain and questioning a few SP issues.
Certainly the BR is not co-resident with the BNG/CMTS but when the  BR
is not I have already said where is the extra protocol to communicate
between the different BNG's/CMTS 's and the BR's to sunset 6rd?   I will
reply to Mark's response in another email.

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Mon, 28 Nov 2011 07:37:33 +0100

> **  Biased Operator View **

Precisely the right forum for such.

> In my opinion, the simpler the requirements on the CPE the better (especially when it comes to how the CPE interacts with the network).   You cannot imagine the /fun/ we have with CPE behaviour today in our networks (coming from all kinds of places and vendors),  I would suggest too much more complexity on the CPE would exasperate this.

I'm trying to boil down the CPE requirements to the point that, when it comes to 6rd and native interaction, it is very simple and predictable so that the operator can control the sunsetting. While I am aware that some CPEs are trying to do so, I think it is more troublesome when the CPE tries to automatically prefer one configuration vs. another as it is more logic for the standards forums to define and the CPE folks to follow.
 
- Mark

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

---

From: Mark Townsley <[email-masked]>
Date: Mon, 28 Nov 2011 07:42:38 +0100

On Nov 28, 2011, at 12:34 AM, Hemant Singh (shemant) wrote:

>  
>  
> Agreed.  However, I am not discussing the CPE router.   I am discussing the SP 6rd and native IPv6 domain and questioning a few SP issues.   Certainly the BR is not co-resident with the BNG/CMTS but when the  BR is not I have already said where is the extra protocol to communicate between the different BNG’s/CMTS ‘s and the BR’s to sunset 6rd?  

The BNG/CMTS and BR do not need an "extra protocol." I'm at a complete loss as to where you are dreaming up this requirement. 

> I will reply to Mark’s response in another email.

When/if you do, please describe why in the world you think the BNG/CMTS and the 6rd BR need to "communicate" with one another.

- Mark

---

From: Wes Beebee <[email-masked]>
Date: Mon, 28 Nov 2011 09:23:15 -0500

> I'm trying to boil down the CPE requirements to the point that, when it comes
> to 6rd and native interaction, it is very simple and predictable so that the
> operator can control the sunsetting. While I am aware that some CPEs are
> trying to do so, I think it is more troublesome when the CPE tries to
> automatically prefer one configuration vs. another as it is more logic for the
> standards forums to define and the CPE folks to follow.

A packet comes into the CE router from a host in the home and is destined
out of the home.  Is that packet encapsulated or not?

We HAVE to be able to answer that question in a completely deterministic and
consistent manner.

- Wes

---

From: Mark Townsley <[email-masked]>
Date: Mon, 28 Nov 2011 16:30:55 +0100

> We HAVE to be able to answer that question in a completely deterministic and

To get your answer, I will ask you to first think of the 6rd interface as like any other interface, just virtual rather than physical. Also, that this virtual interface has two associated RIB entries, one for "CE to CE" traffic, and another "default route" for Internet destined traffic. 

Since most networks beyond the CE will drop packets which are not sourced from within the delegated prefix for the given CE interface, the CE must route packets by their source address to the CE interface which has the correct associated delegated prefix. I believe you have captured this requirement in 6204bis, it just needs to apply to the 6rd virtual interface in the same way as any other interface with its own delegated prefix. 

If there happen to be two interfaces with the same delegated prefix (one of the cases listed in 6rd-sunsetting), then the CE must decide which to send the packet on. Everything else being equal, physical over virtual is probably a good metric to have, and it works well in this case as well. So, for the specific case of one 6rd and one native interface, Internet-destined traffic should always prefer native over 6rd.

The more-specific "CE-to-CE" route continues to point to the 6rd virtual interface, so traffic destined for within the 6rd domain continues to be encapsulated and sent directly to other CEs (without traversing the BR). 

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 09:44:49 -0600

Mark,

As I have already said in another email that either a protocol is needed
between the BR and the BNG/CMTS or an ad hoc set of steps to sunset 6rd.
The ad hoc set of steps to sunset will work and thus we can dispense
with any new protocol.    

Hemant

From: Mark Townsley [mailto:[email-masked]] 
Sent: Monday, November 28, 2011 1:43 AM
To: Hemant Singh (shemant)
Cc: Victor Kuarsingh; Tina TSOU; Alexandre Cassen; [email-masked];
Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

 

between the different BNG's/CMTS 's and the BR's to sunset 6rd?  

The BNG/CMTS and BR do not need an "extra protocol." I'm at a complete
loss as to where you are dreaming up this requirement. 

I will reply to Mark's response in another email.

When/if you do, please describe why in the world you think the BNG/CMTS
and the 6rd BR need to "communicate" with one another.

- Mark

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Mon, 28 Nov 2011 16:47:01 +0100

On Nov 28, 2011, at 4:44 PM, Hemant Singh (shemant) wrote:

> Mark,
>  
> As I have already said in another email that either a protocol is needed between the BR and the BNG/CMTS or an ad hoc set of steps to sunset 6rd.   The ad hoc set of steps to sunset will work and thus we can dispense with any new protocol.    

Great. As long as we agree not to invent a protocol here, I'm happy. 

- Mark

> Cc: Victor Kuarsingh; Tina TSOU; Alexandre Cassen; [email-masked]; Claire Cheng

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 10:24:12 -0600

Mark,

Ad hoc steps are fine and we can skip defining any new protocol between
the BNG and the BR.   Please see below for a response to your "trying to
boil down the CPE requirements".   

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Townsley
Sent: Monday, November 28, 2011 1:38 AM
To: Victor Kuarsingh
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>I'm trying to boil down the CPE requirements to the point that, when it
comes to 6rd and native interaction, it is very simple and predictable
so >that the operator can control the sunsetting. While I am aware >that
some CPEs are trying to do so, I think it is more troublesome when the
CPE >tries to automatically prefer one configuration vs. another as it
is more logic for the standards forums to define and the CPE >folks to
follow.

The Coexistence section of rfc6204bis in section 4.4.3 in bullet 5 and
the last paragraph already includes everything the CPE needs to do for
6rd and native interaction.  Folks should review the complete text below
and please point out what is missing that does not take care of CPE
router requirements that address (a) concurrent 6rd and native IPv6
operation, (b) sunsetting 6rd for both cases of native IPv6 prefix being
same or different than the 6rd prefix, (c) provide a use case that
explains why 6rd and native IPv6 run concurrently (in the last paragraph
with text related to RFC 4862 and the two-hour rule).   Apparently the
use case was not known to some folks.  Again, bullet 5 outlines
concurrent operation of 6rd and native IPv6 while the last paragraph of
the section outlines how 6rd is sunset.  The last paragraph is pertinent
to only when 6rd and native IPV6 use different prefixes with text such
as "multiple prefixes" used in the paragraph.  When prefixes are same,
there is a no-op on the CPE for any 6rd  prefix deprecation.  Further,
the deprecation of 6rd occurs when the CPE DHCPv4 Renew is not responded
to by the SP provisioning system and that forces the CPE to reset
DHCPv4.  On a new DHCPv4, the SP provisioning system does not return the
6rd DHCPv4 option and the CPE disables 6rd.  Note 6rd is already
disabled when the CPE resets to kick of a new DHCPv4.  

 

  [During a sunsetting activity such as deprecating 6rd and moving to
   native IPv6, the IPv6 CE router MUST immediately advertise the 6rd
   prefix with a Preferred Lifetime of zero and a Valid Lifetime of the
   lower of the current Valid Lifetime and two hours (which must be
   decremented in real time) in a Router Advertisement message as
   described in Section 5.5.3, (e) of [RFC4862].  Due to the two hours
   rule specified in [RFC4862], the 6rd and the native IPv6 prefix will
   coexist in the home network.  The two hours rule specified in section
   5.5.3 of [RFC4862] causes any deprecated prefix to linger on the node
   even when an RA has sent a Preferred Lifetime of zero to expire the
   prefix to the node.  During such coexistence of multiple prefixes,
   the CE router sends an ICMPv6 error for packets sourced or destined
   related to the deprecated prefix.  Note this document already
   includes text in bullet L-14 in section 4.3 for such a provision.]

Thanks,

Hemant

---

From: Tom Taylor <[email-masked]>
Date: Mon, 28 Nov 2011 11:34:56 -0500

Below, snipped to key points.

> On Nov 28, 2011, at 3:23 PM, Wes Beebee wrote:
...
>>
>> A packet comes into the CE router from a host in the home and is
>> destined out of the home.  Is that packet encapsulated or not?
>>
>> We HAVE to be able to answer that question in a completely
>> deterministic and consistent manner.
>
...
>
> If there happen to be two interfaces with the same delegated prefix
> (one of the cases listed in 6rd-sunsetting), then the CE must decide
> which to send the packet on. Everything else being equal, physical
> over virtual is probably a good metric to have, and it works well in
> this case as well. So, for the specific case of one 6rd and one
> native interface, Internet-destined traffic should always prefer
> native over 6rd.
>
[PTT] It would be a mistake to send encapsulated packets over the 
physical interface. This is Wes's point: how to avoid that mistake?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 11:33:14 -0600

Tom,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tom Taylor
Sent: Monday, November 28, 2011 11:35 AM
To: Mark Townsley
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>physical interface. This is Wes's point: how to avoid that mistake?

See bullets 5 and 6 from section 4.4.3 of rfc6404bis which is at

For your convenience, the bullets are reproduced below as well.

       different prefixes.]

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Mon, 28 Nov 2011 18:36:52 +0100

On Nov 28, 2011, at 5:34 PM, Tom Taylor wrote:

> [PTT] It would be a mistake to send encapsulated packets over the physical interface. This is Wes's point: how to avoid that mistake?

IPv6 traffic destined outside the 6rd domain should be over the native link, with no encapsulation in IPv4. 

Traffic destined for within the 6rd domain ("CE to CE traffic") will most likely traverse a shorter path if encapsulated in IPv4, and does not require traversal of the 6rd BR path as well.  So, this traffic continues over 6rd until 6rd can be fully disabled on the CE. 

The idea here is to choose what is most likely the shortest path, and to reduce BR utilization. 

- Mark

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 28 Nov 2011 13:10:32 -0500

Mark,

>Traffic destined for within the 6rd domain ("CE to CE traffic") will most
>likely traverse a shorter path if encapsulated in IPv4, and does not
>require traversal of the 6rd BR path as well.  So, this traffic continues
>over 6rd until 6rd can be fully disabled on the CE.
>

* Sorry for long email....

I am not trying to be too disruptive in this thread, but did want to note
a few points (which you may or may not agree with).

I think we are assuming that the CE to CE path would be "shortest" if
using 6RD directly on both endpoints (where one is now Native v6/6RD and
the other only 6RD). In my mind, "shortest" path would also include
performance and overall delay to get form one host to the other (home
network host to home network host).

I think that the performance of the 6RD function (I.e.
Encapsulation/decapsulation performance) on the CE would be a factor when
compared to a network placed/resident BR.  Also, the placement of BRs may
be be optimally placed such that the actual network path may be similar
(but unless co-located with the BNG there will be uses cases where this
may not be possible).

If utilization on the BR is not the key point here, then how important is
CE to CE performance (let's say that there is a small to measurable
difference) when considering the entire transition eco-system?  Does
making this specific flow type (one flow use case) warrant us solving this
issue by adding in state/routing complexity into the CPE to achieve this?

In my mind (which seems to be somewhat at odds with others), I would want
to choose an option which would cause a device to stop doing 6RD when
Native IPv6 is available (bias declared).

I say this since it would add a level of determinism to what I would
expect (say an operator has only course level control as to what
parameters they give each CPE).  This type of determinism goes a long way
for operations and customer care folks (when troubleshooting problems).

I am not saying we cannot make the suggested behaviour (as per drafts in
discussion) work, but other then some optimizations on the CE to CE flows
(within a given 6RD domain), are there other significant gains? (perhaps I
am somewhat ignorant to the gambit of benefits).

(this next point may be a bit off topic)

If re-addressing is one of the the big issues, I am not sure if this can
be avoided (in totality).  6RD to Native IPv6 transition is just one use
case where I need to re-address a CPE/home network.  I have all sorts of
uses cases where this will happen - so we will need to solve the IPv6
renumbering/stability case anyway.  In our network, I would see the move
from 6RD to Native IPv6 (in the prefix retention case) a renumbering
exercise from one Interface type to another (if I can figure out how to
offer the same prefix and not break all types of rules and provisioning
systems at the same time).

Again, I would prefer a cut over from one interface to the other (virtual
to native).  This is what I would ask my vendor to implement.  Once I add
in Native to a capable CPE, I would expect the CPE to go native. I am
hoping there is an option for this within all the proposals.

Sorry to be potentially digging up old bones on this.. I tried to review
entire email thread.

Thoughts?

Victor K

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 12:20:00 -0600

Mark,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Townsley
Sent: Monday, November 28, 2011 12:37 PM
To: Tom Taylor
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>Traffic destined for within the 6rd domain ("CE to CE traffic") will
most likely traverse a shorter path if encapsulated in IPv4, and does
not require traversal >of the 6rd BR path as well.  So, this traffic
continues over 6rd until 6rd can be fully disabled on the CE. 

>The idea here is to choose what is most likely the shortest path, and
to reduce BR utilization. 

Good rule above.  If you see RFC 3484, its section 6, and Rule 7, the
rule specifies what you have mentioned above.  

Hemant

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 28 Nov 2011 14:01:51 -0500

Yes, We still need manual configuration. Not all access networks
currently have DHCPv4 servers (e.g., PPPoE), so it will not be possible
to supply 6rd config via DHCPv4. Some consumers will be happy to get
TR-069-managed routers from their ISP, which will take care of
automating 6rd config for them. But there exist people who do not like
or want to use an ISP router. They want to use their own. And they
should have that right. Manual configuration is for them.

I see no need for additional guidance. To me, the context of the "manual
configuration" requirement makes it clear that we are talking about
exactly the same parameters as the DHCPv4 6rd option. Those parameters
are all non-customer-specific. They can be easily conveyed to the type
of people who would want to use an off-the-shelf router for this
purpose. There's nothing special about them.

Barbara

From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Wednesday, November 23, 2011 10:42 AM
To: Mark Townsley
Cc: STARK, BARBARA H; [email-masked]
Subject: RE: [v6ops] 6rd Sunsetting

Mark,

Hemant

 

- Mark

 

 

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Mon, 28 Nov 2011 20:07:50 +0100

> Native IPv6 is available (bias declared).

You get exactly this by using the model #1, where you bring up native and 6rd with different delegated prefixes. 

> am somewhat ignorant to the gambit of benefits).

We chose what was the most obvious in terms of following general principles of routing, which is why I wanted to answer Wes' question more generally than what he asked.
	
Of course, you *could* send all traffic over the native link, and if you have granular control over the CPE that can be done, but you cannot control the other 6rd CEs in the deployment that do not yet have a native link and will be sending you traffic over the 6rd tunnel. 

Back to general principles: 6rd installs two routes, one "more specific" with the magic of mapping to individual CEs, the other for "the Internet". If you combine this with a native interface that has nothing other than a default route for "the Internet" then you naturally end up with 6rd remaining for the CE-CE more specific route and an equivalent route for "the Internet" that requires a tie-breaker. The tie is broken by preferring native over virtual.

If you are sunsetting in the "same prefix" mode, you are *required* to leave 6rd up to receive traffic from other 6rd CEs (else you blackhole that traffic, there is no scalable way around it). To me it actually seems "less surprising" operationally to have all CE-to-CE traffic being sent and received over 6rd than some CE to CE traffic going up over native and returning encapsulated by the BR and some going direct depending on whether the native link of your peer CE is up or not. 

But, again, if you want to keep the native and 6rd deployment very separate, you can do that via separate prefixes. This "more deterministic" property in the network comes at the expense of the CE being able to handle multihoming properly, or the home handling a flash renumber. These are the 3 fundamental tradeoff areas. I'm striving to allow you to make that operational choice. 

> systems at the same time).

The "same prefix" mode doesn't aim to eliminate renumbering, it just allows you to divorce the 6rd to native migration from requiring it. So, it becomes one less reason to have to renumber, and one less thing in the checklist of issues, when sunsetting 6rd. I'm trying to make it easier for you to turn off 6rd, not harder ;-)

Of course, there could be a dozen other reasons why you might need to renumber (please ask the renum WG to put residential in their charter ;-). 

> hoping there is an option for this within all the proposals.

I don't want to limit the ability for you to move a customer from 6rd to native immediately, but I want others to be able to do it incrementally as well. If you want to move them immediately, all you need to do is provision DHCPv6 PD at the same time you deprovision the 6rd option in DHCPv4 and be sure you use a different prefix for native than 6rd. Once the home router reboots or the DHCPv4 lease and associated 6rd delegated prefix lifetime times out, the 6rd and its associated prefix will be gone never to return. 

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 13:10:52 -0600

Barbara,

Thanks for your input.   We will keep the manual 6rd config in
rfc6204bis.

Hemant

From: STARK, BARBARA H [mailto:[email-masked]] 
Sent: Monday, November 28, 2011 2:02 PM
To: Hemant Singh (shemant); Mark Townsley
Cc: [email-masked]
Subject: RE: [v6ops] 6rd Sunsetting

Barbara

Mark,

Hemant

 

- Mark

 

 

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Mon, 28 Nov 2011 20:17:39 +0100

On Nov 28, 2011, at 8:01 PM, STARK, BARBARA H wrote:

> Yes, We still need manual configuration. Not all access networks currently have DHCPv4 servers (e.g., PPPoE), so it will not be possible to supply 6rd config via DHCPv4.

DHCPv4 can be run over PPPoE for options not supplied in PPP (see DHCP INFORM message). This has been the standard answer from pppext just about every time we have tried to add any new IP config options to IPCP. 

That said, if you think this: 

http://tools.ietf.org/html/draft-freedman-pppext-ipv6-6rd-00

...would be useful and BNG+CE vendors would actually implement it, please speak up:

> Some consumers will be happy to get TR-069-managed routers from their ISP, which will take care of automating 6rd config for them. But there exist people who do not like or want to use an ISP router. They want to use their own. And they should have that right. Manual configuration is for them.
>  
> I see no need for additional guidance. To me, the context of the “manual configuration” requirement makes it clear that we are talking about exactly the same parameters as the DHCPv4 6rd option. Those parameters are all non-customer-specific. They can be easily conveyed to the type of people who would want to use an off-the-shelf router for this purpose. There’s nothing special about them.

OK, I won't stand in the way of including manual requirements under protest, but if they go in then it becomes that much more important that the CE be able to rationalize 6rd and native at the same time. I don't think it changes the requirements at all if we follow the same general principle that the CE "does what it is told" rather than trying to enable and disable 6rd configuration dynamically based on the presence of native IPv6. 

- Mark

> Thanks.  I agree.  Barbara,  based on Mark’s reply, do we still need manual configuration for 6rd in rfc6204bis and if so, what more for guidance would you like?
>  
> Hemant
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 13:25:26 -0600

From: Mark Townsley [mailto:[email-masked]] 
Sent: Monday, November 28, 2011 2:18 PM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); [email-masked]
Subject: Re: [v6ops] 6rd Sunsetting

>OK, I won't stand in the way of including manual requirements under
protest, but if they go in then it becomes that much more important that
the CE be able to rationalize 6rd and native at the same time. I >don't
think it changes the requirements at all if we follow the same general
principle that the CE "does what it is told" rather than trying to
enable and disable 6rd configuration dynamically based on the >presence
of native IPv6. 

The retail, manually-configured CPE will be fine with 6rd sunsetting
based on the rules already specified in rfc6204bis.  The rules are
agnostic to a SP-managed or a user-configured 6rd CPE router. The retail
CPE will start native IPv6 operation when cued to do so with a RA from
the SP BNG and sunset 6rd when the DHCPv4 lease_time expires and the SP
does not reply to the DHCPv4 Renew from the CPE and the SP has also
changing the provisioning system to not include the 6rd DHCPv4 option in
DHCPv4 responses.

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 13:38:38 -0600

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Townsley
Sent: Monday, November 28, 2011 2:08 PM
To: Victor Kuarsingh
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>You get exactly this by using the model #1, where you bring up native
and 6rd with different delegated prefixes. 

Including the fact that the current -03 version of rfc6204bis addresses
the model above correctly with bullet 5 in section 4.4.3.

>Back to general principles: 6rd installs two routes, one "more
specific" with the magic of mapping to individual CEs, the other for
"the >Internet". If you >combine this with a native interface that has
nothing other than a default route for "the Internet" then you naturally
end up >with 6rd remaining for the CE-CE >more specific route and an
equivalent route for "the Internet" that requires a tie-breaker. The tie
is broken by >preferring native over virtual.

Including the fact that the current -03 version of rfc6204bis addresses
the model above correctly with bullet 5 in section 4.4.3.

>If you are sunsetting in the "same prefix" mode, you are *required* to
leave 6rd up to receive traffic from other 6rd CEs (else you blackhole
that >traffic, there >is no scalable way around it). 

Including the fact that the current -03 version of rfc6204bis addresses
the issue Mark mentioned above in the last paragraph of section 4.4.3.
6rd is maintained as long as the SP does not disable 6rd via DHCPv4.
See more details in

http://www.ietf.org/mail-archive/web/v6ops/current/msg11428.html

>I don't want to limit the ability for you to move a customer from 6rd
to native immediately, but I want others to be able to do it
incrementally >as well. If you >want to move them immediately, all you
need to do is provision DHCPv6 PD at the same time you deprovision the
6rd option in >DHCPv4 and be sure you use a >different prefix for native
than 6rd. Once the home router reboots or the DHCPv4 lease and
associated 6rd delegated >prefix lifetime times out, the 6rd and its
>associated prefix will be gone never to return. 

Correct.  The above text is a SP function (to immediately turn off 6rd
when native IPv6 is turned on) and does not add any new text to -03
rfc6404bis document.

Hemant

---

From: [email-masked]
Date: Mon, 28 Nov 2011 15:25:53 -0500

<another-operator-view>
Following on Victor's comments...

+1

> for operations and customer care folks (when troubleshooting problems).
+1. This is a huge operational gain. 

> case where I need to re-address a CPE/home network. 

I just don't see user re-addressing being such a big pain compared to 
the pain of implementing 6RD sunset. This requires 1) important changes in 

CPE implementations, 2) the same prefix length on 6RD and native and 
3) major pain in network architecture if both IPv4 and IPv6 internal 
aggregation are not aligned. 

On 3), my point here is that 6RD sunset will only work if 6RD adressing 
space (based on IPv4) and native v6 PD space align nicely. Any gain 
in aggregation brought by native IPv6 will disappear if v4 aggregation 
is not already done nicely (which is certainly not the case in many 
networks I've seen). 

+1

</another-operator-view>
/JFT

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 14:50:30 -0600

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Monday, November 28, 2011 3:26 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] 6rd Sunsetting

>> hoping there is an option for this within all the proposals.

That is what the intent is in rfc6204bis.  Please see text in bold below
from section 4.4.3 of rfc6204bis.  I said already in another email today
when the 6rd prefix and native IPv6 prefix are the same, we have a no-op
in the CPE for  any functionality listed in the text below.

Hemant

---

From: Tina TSOU <[email-masked]>
Date: Tue, 29 Nov 2011 03:35:04 +0000

Hi,
How does "the CPE has to ensure that it sends packets over the right interface"?
Lets say you have 6rd prefix 2002::/16 which is also the native IPv6 prefix. So if we have a static route like "ipv6 static route 2002::/16 tunnel-interface", how can we have another static route for this prefix with native IPv6 interface?

Tina

From: Mark Townsley <[email-masked]<mailto:[email-masked]>>
Date: November 23, 2011 6:45:27 AM PST
To: Gert Doering <[email-masked]<mailto:[email-masked]>>
Cc: Alexandre Cassen <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Claire Cheng <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] 6rd Sunsetting

- Mark

Hi,

Gert Doering
      -- NetMaster

[email-masked]<mailto:[email-masked]>

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 21:43:37 -0600

Victor,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Victor Kuarsingh
Sent: Monday, November 28, 2011 1:11 PM
To: Mark Townsley; Tom Taylor
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>network host to home network host).

Good use case.  Note the rule that Mark specified, as I said, is already
part of RFC 3484, section 6, and Rule 7.  Thus a CPE is entitled to use
the rule 7 and rfc6204bis can still be silent about this rule because
the rule is already specified in RFC 3484.  So here is a potential
solution for the problem above.  If a mistake is made, we need the
network path to issue an ICMPv6 Destination Unreachable back to the
source.  The network path constitutes a direct CPE to CPE path or a path
through the BR.  Thus even when the destination CPE has disabled 6rd to
operate in native IPv6 mode, or the BR has disabled 6rd, each device
still maintains processing for protocol 41.  If protocol 41 processing
is maintained then the BR or the CPE in native IPv6 mode issues an
ICMPv4/ICMPv6 Destination Unreachable.  Barbara can confirm being a DSL
person, but I think direct CE to CE communications in 6rd and DSL is not
really direct.  The data flows thru a BNG or some router.  At least in a
cable network the traffic between two CPEs has to flow through the CMTS
even if the CPEs span the same IPv6 link.  Thus the BNG processes
protocol 41 as well and issues ICMPv4/ICMPv6 Destination Unreachable to
the source CPE.  This solution is agnostic to whether the receiving CPE
changed mode to a different native IPv6 prefix or same IPv6 prefix as
the 6rd prefix.  Likewise the solution is also agnostic to where the BR
and the BNG are co-located or separate - appropriate routes have to be
injected in the BR and the BNG when they are separate. 

Thanks and regards,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Nov 2011 22:10:29 -0600

Tina,

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tina TSOU
Sent: Monday, November 28, 2011 10:35 PM
To: [email-masked]
Cc: Alexandre Cassen; [email-masked]; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>Lets say you have 6rd prefix 2002::/16 which is also the native IPv6
prefix. So if we have a static route like >"ipv6 static route 2002::/16
tunnel-interface", how can we have >another static route for this prefix
with native >IPv6 interface?

See a configuration example from my IPv6 router for a static IPv6 route
supporting two different network interfaces.

rtr# show run | I ipv6 route

ipv6 route 3001:1234:5678::/48 Bundle1

ipv6 route 3001:1234:5678::/48 GigabitEthernet4/0/0

rtr#

rtr#sh ipv6 route

...

S   3001:1234:5678::/48 [1/0]

     via GigabitEthernet4/0/0, directly connected

     via Bundle1, directly connected

For the same prefix between 6rd and native IPv6, the native IPv6 link is
preferred as specified in bullet 5 of section 4.4.3 of rfc6204bis.

Hemant

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Nov 2011 12:07:17 +0100

Hemant,

I don't want to be blunt, but you are spreading misinformation.

a router forwarding packets does not use RFC3484. that's for hosts.
a router in forwarding tunnelled packets (like the CMTS or the BNG in your example) does _NOT_ process the payload packet in any way. that's kinda the point with tunnels.

cheers,
Ole

> Good use case.  Note the rule that Mark specified, as I said, is already part of RFC 3484, section 6, and Rule 7.  Thus a CPE is entitled to use the rule 7 and rfc6204bis can still be silent about this rule because the rule is already specified in RFC 3484.  So here is a potential solution for the problem above.  If a mistake is made, we need the network path to issue an ICMPv6 Destination Unreachable back to the source.  The network path constitutes a direct CPE to CPE path or a path through the BR.  Thus even when the destination CPE has disabled 6rd to operate in native IPv6 mode, or the BR has disabled 6rd, each device still maintains processing for protocol 41.  If protocol 41 processing is maintained then the BR or the CPE in native IPv6 mode issues an ICMPv4/ICMPv6 Destination Unreachable.  Barbara can confirm being a DSL person, but I think direct CE to CE communications in 6rd and DSL is not really direct.  The data flows thru a BNG or some router.  At least in a cable network the traffic between two CPEs has to flow through the CMTS even if the CPEs span the same IPv6 link.  Thus the BNG processes protocol 41 as well and issues ICMPv4/ICMPv6 Destination Unreachable to the source CPE.  This solution is agnostic to whether the receiving CPE changed mode to a different native IPv6 prefix or same IPv6 prefix as the 6rd prefix.  Likewise the solution is also agnostic to where the BR and the BNG are co-located or separate – appropriate routes have to be injected in the BR and the BNG when they are separate.
>  
> Thanks and regards,
>  
> Hemant
>  
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 29 Nov 2011 07:53:21 -0600

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Tuesday, November 29, 2011 6:07 AM
To: Hemant Singh (shemant)
Cc: Victor Kuarsingh; Mark Townsley; Tom Taylor; Alexandre Cassen;
[email-masked]

>a router in forwarding tunnelled packets (like the CMTS or the BNG in
your example) does _NOT_ process the payload packet in any way. >that's
kinda the point with tunnels.

The CE router is doing source-based forwarding and will switch tunneled
or native for different prefixes between native and 6rd.  The rule that
Mark specified is the same rule as in RFC 3484 to decide between
tunneled vs. native.  It's a matter of opinion what text to use and add
to any of townsley or the rfc6204bis document.  Anyway, back to the use
case that Victor raised.  First the use case makes sense to add to the
townsley 6rd sunsetting document.  Then we discuss the solution for the
problem that the use case raises. 

Hemant

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 29 Nov 2011 11:07:21 -0600

Hi Ole,

What Hemant is saying, i.e. packets always go to BNG from CE is correct.
CE to CE routing idea makes sense in case BR or CGN are located far from
BNG.

Regards,

Behcet

On Tue, Nov 29, 2011 at 5:07 AM, Ole Troan <[email-masked]> wrote:

> a router in forwarding tunnelled packets (like the CMTS or the BNG in your
> example) does _NOT_ process the payload packet in any way. that's kinda the
> point with tunnels.
>
> cheers,
> Ole
>
> part of RFC 3484, section 6, and Rule 7.  Thus a CPE is entitled to use the
> rule 7 and rfc6204bis can still be silent about this rule because the rule
> is already specified in RFC 3484.  So here is a potential solution for the
> problem above.  If a mistake is made, we need the network path to issue an
> ICMPv6 Destination Unreachable back to the source.  The network path
> constitutes a direct CPE to CPE path or a path through the BR.  Thus even
> when the destination CPE has disabled 6rd to operate in native IPv6 mode,
> or the BR has disabled 6rd, each device still maintains processing for
> protocol 41.  If protocol 41 processing is maintained then the BR or the
> CPE in native IPv6 mode issues an ICMPv4/ICMPv6 Destination Unreachable.
>  Barbara can confirm being a DSL person, but I think direct CE to CE
> communications in 6rd and DSL is not really direct.  The data flows thru a
> BNG or some router.  At least in a cable network the traffic between two
> CPEs has to flow through the CMTS even if the CPEs span the same IPv6 link.
>  Thus the BNG processes protocol 41 as well and issues ICMPv4/ICMPv6
> Destination Unreachable to the source CPE.  This solution is agnostic to
> whether the receiving CPE changed mode to a different native IPv6 prefix or
> same IPv6 prefix as the 6rd prefix.  Likewise the solution is also agnostic
> to where the BR and the BNG are co-located or separate – appropriate routes
> have to be injected in the BR and the BNG when they are separate.
> >
> > Thanks and regards,
> >
> > Hemant
> >
> >

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Nov 2011 18:10:52 +0100

Bechet,

> What Hemant is saying, i.e. packets always go to BNG from CE is correct.

not quite. he says the BNG does protocol 41 processing.
from the BNG perspective a 6rd packet is just another IPv4 packet. as for all other routers between the tunnel end points.

> CE to CE routing idea makes sense in case BR or CGN are located far from BNG.

we're not discussing the "idea". 6rd is a mesh link and CE to CE is an intrinsic property of 6rd.

cheers,
Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 29 Nov 2011 11:54:42 -0600

Should we file an errata against RFC5969 when it says 

[The 6rd link is modeled as an NBMA link similar to other automatic

IPv6 in IPv4 tunneling mechanisms like [RFC5214], with all 6rd CEs

and BRs defined as off-link neighbors from one other.]

Off-link means a node sends traffic to the default router(s) rather than
communicating directly with another client on the link.  With text
above, all 6rd CEs are off-link to each other, so how is a CE
communicating directly to another CE as Barbara has also alluded to?

Hemant

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Tuesday, November 29, 2011 12:11 PM
To: [email-masked]
Cc: Hemant Singh (shemant); Alexandre Cassen; [email-masked]
Subject: Re: [v6ops] 6rd Sunsetting

Bechet,

from the BNG perspective a 6rd packet is just another IPv4 packet. as
for all other routers between the tunnel end points.

> CE to CE routing idea makes sense in case BR or CGN are located far
from BNG.

we're not discussing the "idea". 6rd is a mesh link and CE to CE is an
intrinsic property of 6rd.

cheers,

Ole

> a router in forwarding tunnelled packets (like the CMTS or the BNG in
your example) does _NOT_ process the payload packet in any way. that's
kinda the point with tunnels.

> > Good use case.  Note the rule that Mark specified, as I said, is
already part of RFC 3484, section 6, and Rule 7.  Thus a CPE is entitled
to use the rule 7 and rfc6204bis can still be silent about this rule
because the rule is already specified in RFC 3484.  So here is a
potential solution for the problem above.  If a mistake is made, we need
the network path to issue an ICMPv6 Destination Unreachable back to the
source.  The network path constitutes a direct CPE to CPE path or a path
through the BR.  Thus even when the destination CPE has disabled 6rd to
operate in native IPv6 mode, or the BR has disabled 6rd, each device
still maintains processing for protocol 41.  If protocol 41 processing
is maintained then the BR or the CPE in native IPv6 mode issues an
ICMPv4/ICMPv6 Destination Unreachable.  Barbara can confirm being a DSL
person, but I think direct CE to CE communications in 6rd and DSL is not
really direct.  The data flows thru a BNG or some router.  At least in a
cable network the traffic between two CPEs has to flow through the CMTS
even if the CPEs span the same IPv6 link.  Thus the BNG processes
protocol 41 as well and issues ICMPv4/ICMPv6 Destination Unreachable to
the source CPE.  This solution is agnostic to whether the receiving CPE
changed mode to a different native IPv6 prefix or same IPv6 prefix as
the 6rd prefix.  Likewise the solution is also agnostic to where the BR
and the BNG are co-located or separate - appropriate routes have to be
injected in the BR and the BNG when they are separate.

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Nov 2011 19:29:14 +0100

Hemant,

> Off-link means a node sends traffic to the default router(s) rather than communicating directly with another client on the link.  With text above, all 6rd CEs are off-link to each other, so how is a CE communicating directly to another CE as Barbara has also alluded to?

following your logic, the CE wouldn't be able to reach the BR (it's default router) either. ;-)
try configuring two routers on a point to point link, with each having an address with prefix length 128. run a routing protocol between them. they are off link. can they reach each other?

cheers,
Ole

---

From: Tina TSOU <[email-masked]>
Date: Tue, 29 Nov 2011 19:45:17 +0000

Yes I have similar example in mind too......I am only unclear as to where we provide the preference for the route over native interface........in the code or there is a configuration command to assign higher priority to the native route.

Tina
From: "Hemant Singh (shemant)" <[email-masked]<mailto:[email-masked]>>
Date: November 28, 2011 8:10:29 PM PST
To: Tina TSOU <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Cc: Alexandre Cassen <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Claire Cheng <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] 6rd Sunsetting
Tina,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Monday, November 28, 2011 10:35 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Alexandre Cassen; [email-masked]<mailto:[email-masked]>; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>Lets say you have 6rd prefix 2002::/16 which is also the native IPv6 prefix. So if we have a static route like >"ipv6 static route 2002::/16 tunnel-interface", how can we have >another static route for this prefix with native >IPv6 interface?

See a configuration example from my IPv6 router for a static IPv6 route supporting two different network interfaces.

For the same prefix between 6rd and native IPv6, the native IPv6 link is preferred as specified in bullet 5 of section 4.4.3 of rfc6204bis.

Hemant

---

From: Tina TSOU <[email-masked]>
Date: Tue, 29 Nov 2011 19:46:42 +0000

As per the mail below from Victor, if we stop 6rd on a CPE completely when native is enabled, what if the destination CPE inside the domain is still only 6rd??This can be reached only through 6rd . The SP can stop 6rd completely only if he is sure that all CPE's in his domain are on native v6 n/w.

Tina
From: Victor Kuarsingh <[email-masked]<mailto:[email-masked]>>
Date: November 28, 2011 10:10:32 AM PST
To: Mark Townsley <[email-masked]<mailto:[email-masked]>>, Tom Taylor <[email-masked]<mailto:[email-masked]>>
Cc: Alexandre Cassen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Claire Cheng <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] 6rd Sunsetting
Mark,

...

...

IPv6 traffic destined outside the 6rd domain should be over the native
link, with no encapsulation in IPv4.

The idea here is to choose what is most likely the shortest path, and to
reduce BR utilization.

Thoughts?

Victor K

- Mark

- Mark

- Wes

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

---

From: Mark Townsley <[email-masked]>
Date: Tue, 29 Nov 2011 21:05:52 +0100

On Nov 29, 2011, at 8:46 PM, Tina TSOU wrote:

> As per the mail below from Victor, if we stop 6rd on a CPE completely when native is enabled, what if the destination CPE inside the domain is still only 6rd??This can be reached only through 6rd . The SP can stop 6rd completely only if he is sure that all CPE’s in his domain are on native v6 n/w.

Exactly.

- Mark

>  
> 
> Tina
> 
> From: Victor Kuarsingh <[email-masked]>
> To: Mark Townsley <[email-masked]>, Tom Taylor <[email-masked]>
> Cc: Alexandre Cassen <[email-masked]>, "[email-masked]" <[email-masked]>, Claire Cheng <[email-masked]>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 29 Nov 2011 14:16:12 -0600

Tina,

At least all router CLI that I have dealt with such as Cisco routers has
an administrative distance argument that is used to assign higher
priority.   

Hemant

From: Tina TSOU [mailto:[email-masked]] 
Sent: Tuesday, November 29, 2011 2:45 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]; Alexandre Cassen; Claire Cheng
Subject: RE: [v6ops] 6rd Sunsetting

Yes I have similar example in mind too......I am only unclear as to
where we provide the preference for the route over native
interface........in the code or there is a configuration command to
assign higher priority to the native route.

---

From: Mark Townsley <[email-masked]>
Date: Tue, 29 Nov 2011 22:12:41 +0100

On Nov 29, 2011, at 9:16 PM, Hemant Singh (shemant) wrote:

> Tina,
>  
> At least all router CLI that I have dealt with such as Cisco routers has an administrative distance argument that is used to assign higher priority.   

As much as IOS config is a wonderful playground for anything and everything one might ever think of configuring, the more important point is to get the defaults nailed down.

IMHO, the default tie-breaker between two otherwise identical routes would specify native with a lower distance than virtual (e.g. 6rd). This means that the native path would be preferred over virtual, everything else being equal. That said, a more-specific prefix still wins over these metrics, and source-based routing even above destination-based forwarding so that the correct interface is chosen in multihoming situations. 

- Mark 

> Yes I have similar example in mind too……I am only unclear as to where we provide the preference for the route over native interface……..in the code or there is a configuration command to assign higher priority to the native route.
>  
>