Subject: Re: [v6ops] 6rd Sunsetting

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 14:49:56 -0800

On Mon, Nov 28, 2011 at 19:43, Hemant Singh (shemant) <[email-masked]>wrote:

> 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.
>
RFC 3484 is not relevant here. It describes how nodes choose source
addressing when originating packets. It doesn't apply to forwarding traffic.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 1 Dec 2011 17:13:17 -0600

Lorenzo,

Agree.    However I am only drawing a parallel with the RFC 3484 rule
for source-based routing - that's all.     For example when PBR routes
based on the source-address, PBR has to first match the source-address
of the packet with an ACL and then apply a PBR rule for next-hop which
for 6rd sunsetting is 6rd vs. native IPv6 each using different prefixes.
This 6rd tunneled vs. native IPv6 source-based forwarding is similar in
principle to the rule 7 of section 6 of RFC 3484.

Also, the rule specified by Mark is a valid rule for CPE router
requirements even with Victor's use case because the network has to
issue an ICMPv4/ICMPv6 Destination Unreachable to the source CPE.
Having thought some more on Victor's use case where source CPE sent 6rd
tunneled packet but the destination CPE switched to native IPv6, if the
CPEs are communicating directly, the source CPE should timeout NUD with
the destination CPE and not even issue any packet on the tunnel to the
destination CPE.  

Hemant

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Thursday, December 01, 2011 5:50 PM
To: Hemant Singh (shemant)
Cc: Victor Kuarsingh; Mark Townsley; Tom Taylor; Alexandre Cassen;
[email-masked]
Subject: Re: [v6ops] 6rd Sunsetting

On Mon, Nov 28, 2011 at 19:43, Hemant Singh (shemant)
<[email-masked]> wrote:

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.

RFC 3484 is not relevant here. It describes how nodes choose source
addressing when originating packets. It doesn't apply to forwarding
traffic.

---

From: Mark Townsley <[email-masked]>
Date: Fri, 2 Dec 2011 00:32:00 +0100

On Dec 2, 2011, at 12:13 AM, Hemant Singh (shemant) wrote:

> Lorenzo,
>  
> Agree.    However I am only drawing a parallel with the RFC 3484 rule for source-based routing – that’s all.     For example when PBR routes based on the source-address, PBR has to first match the source-address of the packet with an ACL and then apply a PBR rule for next-hop which for 6rd sunsetting is 6rd vs. native IPv6 each using different prefixes.   This 6rd tunneled vs. native IPv6 source-based forwarding is similar in principle to the rule 7 of section 6 of RFC 3484.
>  
> Also, the rule specified by Mark is a valid rule for CPE router requirements even with Victor’s use case because the network has to issue an ICMPv4/ICMPv6 Destination Unreachable to the source CPE.  Having thought some more on Victor’s use case where source CPE sent 6rd tunneled packet but the destination CPE switched to native IPv6, if the CPEs are communicating directly, the source CPE should timeout NUD with the destination CPE and not even issue any packet on the tunnel to the destination CPE. 

Are you referring to the "NUD" feature of 6rd? That's mostly for troubleshooting, and only for CE to BR reachability. 

- Mark

> Cc: Victor Kuarsingh; Mark Townsley; Tom Taylor; Alexandre Cassen; [email-masked]
> On Mon, Nov 28, 2011 at 19:43, Hemant Singh (shemant) <[email-masked]> wrote:
> 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.
> 
> RFC 3484 is not relevant here. It describes how nodes choose source addressing when originating packets. It doesn't apply to forwarding traffic.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 1 Dec 2011 17:46:45 -0600

From: Mark Townsley [mailto:[email-masked]] 
Sent: Thursday, December 01, 2011 6:32 PM
To: Hemant Singh (shemant)
Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; Alexandre Cassen;
[email-masked]
Subject: Re: [v6ops] 6rd Sunsetting

>Are you referring to the "NUD" feature of 6rd? That's mostly for
troubleshooting, and only for CE to BR reachability. 

NUD recommended for tunnels from RFC 4213.  

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Fri, 2 Dec 2011 00:52:58 +0100

On Dec 2, 2011, at 12:46 AM, Hemant Singh (shemant) wrote:

> Cc: Lorenzo Colitti; Victor Kuarsingh; Tom Taylor; Alexandre Cassen; [email-masked]

Except that RFC 5969 says:

   A typical 6rd deployment may consist of a very large number of CEs
   within the same domain.  Reachability between CEs is based on IPv4
   routing, and sending NUD or any periodic packets between 6rd CE
   devices beyond isolated troubleshooting of the 6rd mechanism is NOT
   RECOMMENDED.

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 1 Dec 2011 17:57:54 -0600

Sent: Thursday, December 01, 2011 6:53 PM

>   devices beyond isolated troubleshooting of the 6rd mechanism is NOT

For Victor's use case, the source CPE using 6rd has lot network
connectivity to destination CPE.   Would this network connectivity be
good to troubleshoot with NUD?  

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Fri, 2 Dec 2011 01:28:28 +0100

On Dec 2, 2011, at 12:57 AM, Hemant Singh (shemant) wrote:

> For Victor’s use case, the source CPE using 6rd has lot network connectivity to destination CPE.   Would this network connectivity be good to troubleshoot with NUD? 

Troubleshoot from an admin interface, sure. Dynamically keep track of which of the 10 million CPE are "up" and "down", no. You don't do this with IPv4, do you? Please do not think of 6rd as a circuit. 

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 2 Dec 2011 11:43:58 -0600

Sent: Thursday, December 01, 2011 7:28 PM

>Troubleshoot from an admin interface, sure. Dynamically keep track of
which of the 10 million CPE are "up" and "down", no. You don't do this
with IPv4, do you? Please do not think of 6rd as a circuit. 

The 10 million number for CPE is interesting.   A SP should manage their
network that a single BR does not get so many CPEs to support and the
BR.   

Hemant

---

From: Wes Beebee <[email-masked]>
Date: Fri, 02 Dec 2011 13:34:30 -0500

>Troubleshoot from an admin interface, sure. Dynamically keep track of which of
the 10 million CPE are "up" and "down", no. You don't do this with IPv4, do you?
Please do not think of 6rd as a circuit.

If NUD information is needed (ie. from an ICMPv6 generation standpoint),
then one could consider setting REACHABLE_TIME in RFC 4861 and the Reachable
Time in the RA to 1 hour.  I understand that this implies a 1 hour delay
before noticing that a CPE is no longer available, but it may be a good
compromise.

- Wes

---

From: Mark Townsley <[email-masked]>
Date: Mon, 5 Dec 2011 10:45:05 +0100

On Dec 2, 2011, at 7:34 PM, Wes Beebee wrote:

> If NUD information is needed (ie. from an ICMPv6 generation standpoint), then one could consider setting REACHABLE_TIME in RFC 4861 and the Reachable Time in the RA to 1 hour.  I understand that this implies a 1 hour delay before noticing that a CPE is no longer available, but it may be a good compromise.

Still catching up, but I want to respond to this one from a least a few different angles. 

The 6rd "NUD" is an individual CE troubleshooting mechanism. It is not an opportunity to have millions of CEs sending pings and flapping interfaces. You'll spend more time debugging this type of behavior than you will 6rd itself. 

6rd is stateless. It's not like it can get "out of sync" like you might think with other tunneling protocols. Properly deployed by an ISP, it either works or it doesn't. Actively looking for transient behavior and automatically responding is a wild goose chase (with a 1 minute timer or a 1 hour timer, it doesn't matter). 

Free's implementation with ~2 Million homes enabled now does not have any periodic timers tied to 6rd. It's working just fine for 4 years now. 

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Mon, 5 Dec 2011 16:40:10 +0100

On Dec 2, 2011, at 6:43 PM, Hemant Singh (shemant) wrote:

> The 10 million number for CPE is interesting.   A SP should manage their network that a single BR does not get so many CPEs to support and the BR.  

You mean the SP should manage their network so that a given BR doesn't get more traffic than it can handle. The BRs have no concept of how many CPEs they support. 

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 5 Dec 2011 09:56:33 -0600

Sent: Monday, December 05, 2011 10:40 AM

>You mean the SP should manage their network so that a given BR doesn't get more traffic than it can handle. The BRs have no concept of how many CPEs they support. 

Naïve BR implementation.   Any sensible device should be coded defensively to not serve any more 6rd CE if the BR cpu is say, at 50%.  Further, why can't the SP manage their network to load balance between BRs?  

Hemant

---

From: Gert Doering <[email-masked]>
Date: Mon, 5 Dec 2011 17:03:46 +0100

Hi,

On Mon, Dec 05, 2011 at 09:56:33AM -0600, Hemant Singh (shemant) wrote:
> Naïve BR implementation.   Any sensible device should be coded defensively to not serve any more 6rd CE if the BR cpu is say, at 50%.  

Now I'm seriously curious how you think this would be done.

Like, with the non-existing negotiation protocol between BR and CPEs, 
which the CPEs do not use to request 6rd service from the BR, which 
could then prompt the BR to check it's non-existing state database to 
see whether it would like to handle more CPEs, whose *number* would
not have any effect on its load anyway.

> Further, why can't the SP manage their network to load balance between BRs?  

Of course they can.  Which is the upside of the stateless nature of the BR.

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: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 5 Dec 2011 10:57:17 -0600

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: Monday, December 05, 2011 11:04 AM
To: Hemant Singh (shemant)
Cc: Mark Townsley; Alexandre Cassen; [email-masked]
Subject: Re: [v6ops] 6rd Sunsetting

>not have any effect on its load anyway.

What metric is used to load-balance 6rd between two BR's?  Use the same
metric as internal code in a single BR and also make sure the BR cpu
does not go over a certain x% load.  If the load is exceeded, the BR
drops data.

Hemant

---

From: Gert Doering <[email-masked]>
Date: Mon, 5 Dec 2011 19:20:00 +0100

Hi,

On Mon, Dec 05, 2011 at 10:57:17AM -0600, Hemant Singh (shemant) wrote:
> What metric is used to load-balance 6rd between two BR's?  

There is no well-defined metric, except for "looking at the box and 
noticing that you need a bigger one".  

The load-balacing would be done with basic routing - send half the 
traffic this way, half the traffic the other way.

Or anycast BR - send whatever comes in from west coast to BR-west, 
whatever comes from the east coast to BR-east.

("basic routing" will not work for CPE->BR, you need either anycast BR
or 'send different BR address to different clients' here).

As the thing is stateless, it scales great, and will also handle routing
asymmetry (Internet->BR1->CPE and CPE->BR2->Internet) perfectly wel.

> Use the same

Indeed, that's what happens - if 100% load is exceeded, the BR drops
data.

Maybe it's just a language issue, but I'm not sure I understand your
thoughts about the BR's workings - the BR is (by design) completely
stateless, and there are no protocols whatsoever except basic routing
that can influence the traffic level the BR sees.  There is no negotiation
with any other network element.

Gert Doering
        -- NetMaster