Subject: [v6ops] RFC6204bis-02

From: Wuyts Carl <[email-masked]>
Date: Wed, 9 Nov 2011 10:21:11 +0100

All,

Ole has asked me, @ RIPE meeting in Vienna last week, to review the RFC6204bis, basically to see if it would have a lot of impact towards the/our CPE and whether or not it would be useful to publish it with its current content.

Overall, I don't think this version really adds a lot of extra requirements.  This could be a reason to wait however, it "just" adds 6rd/DSlite as basic mechanisms, which is OK + it re-phrases a few of the other requirements.  I think it could also be used to add some extra info on some of the existing RFC6204 requirements (see remarks below on WAA-8 and WPD-5).

I've exchanged a few mails with Ole on this, and he suggested me to bring these things up on v6ops; reason for this mail.  Find my comments below.

1.       DLW-4:  If the IPv6 CE Router is configured with a public IPv4 address on its WAN interface, where public IPv4 address is defined as any address which is not in the private IP address space specified in [RFC5735] and also not in the reserved IP address space specified in [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element.

This one is not fully ok I'd say.  First of all, the DSlite is supposed to run on a v6-only intf, hence you could consider it as a configuration issue in case you have configured a public  IPv4 on it ?  Even if not, I don't see what you should have to check for public IPv4 address presence to bring up (or not) the DSLite intf.

And then what happens if the DSLite tunnel is up, and a public IPv4 is being configured on top ?  Bring it down ?

Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite.  This will bring up the DSLite intf, because of the option, why bothering checking the public IPv4 presence ?

Maybe this is not really an issue, afterall, it's a configuration "mistake".

So my recommendation here would be to remove this requirement.

That's all wrt to RFC6204bis.  I must say, that some of the RFC6204 requirements currently present are not really clear on what they exactly cover, i.e. some of them can be, imho, interpreted in multiple ways hence might lead to some confusion.

2.       WAA-8:  If the IPv6 CE router does not acquire global IPv6 address(es) from either SLAAC or DHCPv6, then it MUST create global IPv6 address(es) from its delegated prefix(es) and configure those on one of its internal virtual network interfaces.

I assume this is describing the situation where the WAN intf does not get an IPv6 addr (not via RA, not via dhcpv6 ia_na).  In this situation, you want to configure one from the delegated prefix on "a virtual network intf (being exactly what, loop ?)".  If the delegated prefix <>64, I don't see an issue, however, if the ia_pd prefix length = 64, this would mean that only the CPE would get an IPv6 address from the ia_pd, and nothing more left to distribute on the LAN OR the only available /64 gets sent to the LAN hosts, but nothing available on the CPE (for remote management).

Ole's answer to this was:

""

in 6204bis this requirement has been weakened with the additional "unless configured to require a global IPv6 address on the WAN interface". to avoid cable CPEs having to comply with this.

the motivation for the original requirement, is to give the CPE an IPv6 address that is independent of LAN side interface state, that can be used for e.g. management of the CPE.

in the case of the single /64, I would use that on the LAN interface and configure an address out of it. if you get more, I would reserve a /64 for "loopback" on the box.

""

And

""

I do agree with your point though, WAA-8 is written under the assumption that a delegated prefix would be larger than a /64.

I don't know if we should fix that, or use it as a signal to ISPs that the practice of only /64 is not going to work well.

""

So I think one cannot rule out the possibility of using /64s.  Maybe it's not (and it should not) be the preferred way but on the other hand, it is allowed.  So my recommendation here would be to add a /64 behavior to avoid confusion or other interpretation.

3.       WPD-5:  If the IPv6 CE router initiates DHCPv6 before receiving a Router Advertisement, it MUST also request an IA_NA option in DHCPv6.

So this is linking RA presence/receiving  with the request for ia_na or not.

I don't think these 2 things should be linked, i.e. the ia_na option will be configured upfront in the DHCPv6 client configuration or not, it should not be added on the fly.

Ole's answer to this:

""

the purpose of this was twofold:

- keep DHCP and RA processing separate (allow for both being done in parallel)

- allow for a single DHCP session for both addresses and prefixes.
""
And
""

yes, unfortunately the M-bit is tied to IA_NA processing.

the latest revision 03 is proposing that _no_ IPv6 DHCP should happen until an RA is received with either M or O = 1.
""
Our opinion on this one is that they should not be linked, so either allow for configuration to listen to RA or not, and act upon it, or just deal with the result, just request both, independent from RA received or not.  Suppose you're on a ptp link, you might not even want to see RA, hence you should not tie yourself up to it, unless you want to make things more complex and start defining exceptions.

My 2 cents
regs

Carl Wuyts
GCD System Architect Networking
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

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.

Carl Wuyts
GCD System Architect Networking
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

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.

---

From: Wes Beebee <[email-masked]>
Date: Wed, 09 Nov 2011 10:42:19 -0500

> 2.       WAA-8:  If the IPv6 CE router does not acquire global IPv6
> address(es) from either SLAAC or DHCPv6, then it MUST create global IPv6
> address(es) from its delegated prefix(es) and configure those on one of its
> internal virtual network interfaces.
>  
> I assume this is describing the situation where the WAN intf does not get an
> IPv6 addr (not via RA, not via dhcpv6 ia_na).  In this situation, you want to
> configure one from the delegated prefix on ³a virtual network intf (being
> exactly what, loop ?)².  If the delegated prefix <>64, I don¹t see an issue,
> however, if the ia_pd prefix length = 64, this would mean that only the CPE
> would get an IPv6 address from the ia_pd, and nothing more left to distribute
> on the LAN OR the only available /64 gets sent to the LAN hosts, but nothing
> available on the CPE (for remote management).

The intent with IA_PD prefix length = 64 is that one /128 from the /64 would
be configured on the internal interface, and the /64 would be advertised on
the LAN for others to get addresses from.  If an NS(DAD) for the loopback
address is received on the LAN interface, the router would respond with an
NA to indicate that the address was already configured on the (internal)
interface (a very unlikely event).

- Wes

---

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

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Wuyts Carl
Sent: Wednesday, November 09, 2011 4:21 AM
To: [email-masked]
Subject: [v6ops] RFC6204bis-02

>1. WPD-5:  If the IPv6 CE router initiates DHCPv6 before receiving a
Router Advertisement, it MUST also request an IA_NA option in DHCPv6.

>Our opinion on this one is that they should not be linked, so either
allow for configuration to listen to RA or not, and act upon it, or just
deal with the result, just request both, independent from RA received or
>not.  Suppose you're on a ptp link, you might not even want to see RA,
hence you should not tie yourself up to it, unless you want to make
things more complex and start defining exceptions.

The attempt is to not link at all.   Note IA_PD acquisition is a router
to router protocol as per RFC 3633 and thus an RA has got nothing to do
with the CE router WAN interface kicking off DHCPv6 for the IA_PD.
Since the IA_PD is being asked of, it was a optimization to also ask for
the IA_NA.   We have a similar optimization in 

[W-5:  DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation

         (IA_PD) SHOULD be done as a single DHCPv6 session.]

That said, cable broadband standards body contacted us to change WPD-4
to "by Default, the IPv6 CE router MUST initiate DHCPv6 prefix
delegation when either the M and or the O flags are set to 1 in a
received Router Advertisement message."  With the new text the cable
standards body can write in their profile specific document that their
eRouter cable modem MUST only initiate DHCPv6 PD on seeing the RA.  If
the WPD-4 original text was not changed, the cable profile document
would be in contradiction with RFC 6204.   However, once the cable
profile is all settled, none of the old behavior for the CE router
changes.   With the new WPD-4 text, the CE router is still legal to
initiate DHCPv6 without seeing an RA or if an RA is seen, the CE doesn't
care what the M and the O bits are.   

Thanks,

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 9 Nov 2011 12:37:18 -0800

On Wed, Nov 9, 2011 at 01:21, Wuyts Carl <[email-masked]> wrote:

> *
> 2.       ****WAA-8:  If the IPv6 CE router does not acquire global IPv6
> internal virtual network interfaces.*
>
> ** **
>
> I assume this is describing the situation where the WAN intf does not get
> an IPv6 addr (not via RA, not via dhcpv6 ia_na).  In this situation, you
> want to configure one from the delegated prefix on “a virtual network intf
> (being exactly what, loop ?)”.  If the delegated prefix <>64, I don’t see
> an issue, however, if the ia_pd prefix length = 64, this would mean that
> only the CPE would get an IPv6 address from the ia_pd, and nothing more
> left to distribute on the LAN OR the only available /64 gets sent to the
> LAN hosts, but nothing available on the CPE (for remote management).
>
No, wait. The CE router gets at least one /64 from PD, possibly more. If it
doesn't have an IPv6 address (from RA, or from DHCPv6 NA) on the WAN
interface, it picks ONE global address from the PD as its global IPv6
address. Since the CE router is a router that's connected to at least one
/64 in the PD, it can just pick an autoconf address from one of those /64s,
assign it to a loopback, and do proxy ND for it on the interface that
"owns" that /64. DAD will take care of it. No?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 9 Nov 2011 12:56:19 -0800

On Wed, Nov 9, 2011 at 01:21, Wuyts Carl <[email-masked]> wrote:

> *Our opinion on this one is that they should not be linked*, so either
> not.  Suppose you’re on a ptp link, you might not even want to see RA,
> hence you should not tie yourself up to it, unless you want to make things
> more complex and start defining exceptions.
>

Having the CE router ask for DHCPv6 regardless of any RA it receives or
does not receive does not allow operators to control their IPv6 rollouts.

The problem is that in steady state, DHCPv6 will send one request every 2
minutes. If those requests are not answered, in a 10M user network with 5%
of CPEs IPv6-capable, that means upwards of 4000 requests per second. That
110x the load of steady-state IPv4, where, say, 100% of CPEs will get a
DHCPv4 lease and not ask again for, say, 3 days. You can't expect an
operator to increase DHCPv6 capacity by over 100x just to roll out IPv6.

In order to roll out IPv6 gradually, the operator needs to signal to the CE
router that "IPv6 is available". The RA is the canonical way to do that
(that's what DHCPv6 was designed to listen to). Unfortunately, making RA
independent from DHCPv6 makes the CE router ignore the signal.

This can cause real scaling issues.

We (where "we" == the organizers of the next World IPv6 event) are working
with retail CE manufacturers who appear to be willing to enable IPv6 by
default in a substantial portion of their products if the event happens.
We're also working with a number of large ISPs, who appear to be willing to
bring IPv6 to single-digit percentages of their users during 1H2012, which
basically, given CPE churn rate, means enabling the majority of the access
network.

The resulting potential effect on those networks' DHCPv6 servers (i.e.,
"burn them down to the ground with a > 100x increase in load") could cause
those networks to slow down those rollouts considerably or not start them
at all until DHCPv6 servers can be forklifted.

You might think that the obvious solution to this is to have the CE router
ask "less frequently", but that also means that the CE router will find out
"less frequently" when connectivity has come back after an outage or
prolonged disconnection (since disconnections may not always correspond to
link flaps). This makes IPv6 less reliable than IPv4, which is not what
anyone wants.

---

From: Wes Beebee <[email-masked]>
Date: Wed, 09 Nov 2011 16:03:28 -0500

Lorenzo -

> The resulting potential effect on those networks' DHCPv6 servers (i.e., "burn
> them down to the ground with a > 100x increase in load") could cause those
> networks to slow down those rollouts considerably or not start them at all
> until DHCPv6 servers can be forklifted.

No one is suggesting that we not solve the problem.  We are taking issue
with HOW you are suggesting to solve the problem.  I, for one, believe that
the issue is really an access concentrator issue, which routinely manages
congestion-control and rate-limits DHCPv6 packets ANYWAY.  It has to - to
protect the DHCPv6 servers from DoS attacks from untrusted CPE routers.

Why not use the mechanisms that are already in place, that require no
specific standards effort, to solve this problem?

- Wes

---

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Wes Beebee (wbeebee)
Sent: Wednesday, November 09, 2011 4:03 PM
To: Lorenzo Colitti; Wuyts Carl
Cc: [email-masked]
Subject: Re: [v6ops] RFC6204bis-02

>specific standards effort, to solve this problem?

+1.  

I do acknowledge that problem of a storm at the DHCPv6 server in an SP
network where the SP is not ready to server DHCPv6.  However, changing
rfc6204bis or any other IETF document to solve the storm does not make
sense.  Folks are suggesting to use the M and the O bits in the RA to
signal DHCPv6 start/stop when such suggestions have thrashed for
multiple years in the IETF 6man and the DHC WG's with no change to the
document in this regard.  I have personally emailed to the SP mitigation
configuration at the access concentrator and so has Ole and others.  If
the SP is not serving DHCPv6, why does the SP even have a access
concentrator configuration to relay DHCPv6 client traffic to a server?
The access concentrator DHCPv6 relay agent operation can be shut down as
well.  

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 9 Nov 2011 14:22:32 -0800

On Wed, Nov 9, 2011 at 13:03, Wes Beebee <[email-masked]> wrote:

> "burn
> with HOW you are suggesting to solve the problem.

I didn't make any suggestions in this thread. That discussion is being
carried out elsewhere with a more limited group of people, because we don't
necessarily want to spam the whole of v6ops with it :-)

All I did was give one important reason why it's not automatically a good
idea to make RS and DHCPv6 PD independent.

Another good reason, which I just realize I forgot to mention, is that from
the perspective of a CE router, having a DHCPv6 PD and no default route is
pointless, because it can't go anywhere anyway. It's also harmful to the
hosts behind it, because even if the CE router is implemented correctly and
does not give the hosts a default route, it will still be giving them
global IPv6 addresses, which will double their DNS lookup latency (because
once they have a global IPv6 address, they will start asking for AAAA
records).

I, for one, believe that the issue is really an access concentrator issue,
> which routinely manages congestion-control and rate-limits DHCPv6 packets
> ANYWAY.  It has to - to

Because every time you rate-limit a DHCP request, that could be a user that
can't get online. If you're hitting rate-limits all the time, you're
denying service to real users all the time.

The problem here is not that one particular CE router asks for DHCP PD too
often - it may be fine for one CE router to make 5 DHCPv6 requests in one
minute, as long as it doesn't happen all the time. It's that when when you
add up millions of CE routers asking every 2 minutes, *all the time* the
aggregate load becomes very large.

---

From: Hans Liu <[email-masked]>
Date: Thu, 10 Nov 2011 12:09:16 +0800

On Wed, Nov 9, 2011 at 5:21 PM, Wuyts Carl <[email-masked]>wrote:

> All,****
>
> ** **
>
> Ole has asked me, @ RIPE meeting in Vienna last week, to review the
> RFC6204bis, basically to see if it would have a lot of impact towards
> the/our CPE and whether or not it would be useful to publish it with its
> current content.****
>
> ** **
>
> Overall, I don’t think this version really adds a lot of extra
> requirements.  This could be a reason to wait however, it “just” adds
> 6rd/DSlite as basic mechanisms, which is OK + it re-phrases a few of the
> other requirements.  I think it could also be used to add some extra info
> on some of the existing RFC6204 requirements (see remarks below on WAA-8
> and WPD-5). ****
>
> ** **
>
> I’ve exchanged a few mails with Ole on this, and he suggested me to bring
> these things up on v6ops; reason for this mail.  Find my comments below.**
> **
>
> ** **
>
> ***1.       ****DLW-4:  If the IPv6 CE Router is configured with a public
> IPv4 address on its WAN interface, where public IPv4 address is defined as
> any address which is not in the private IP address space specified in
> [RFC5735] and also not in the reserved IP address space specified in
> [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element.*
>
> * *
>
> ** **
>
> This one is not fully ok I’d say.  First of all, the DSlite is supposed to
> run on a v6-only intf, hence you could consider it as a configuration issue
> in case you have configured a public  IPv4 on it ?  Even if not, I don’t
> see what you should have to check for public IPv4 address presence to bring
> up (or not) the DSLite intf.****
>
> And then what happens if the DSLite tunnel is up, and a public IPv4 is
> being configured on top ?  Bring it down ?****
>
> Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite.
> This will bring up the DSLite intf, because of the option, why bothering
> checking the public IPv4 presence ?****
>
> Maybe this is not really an issue, afterall, it’s a configuration
> “mistake”.****
>
> ** **
>
> *So my recommendation here would be to remove this requirement.*
>
> **
>
[Hans]: The recommendation looks ok to me. In D-Link implementation, I put
DS-Lite under IPv4 Internet Settings, as one of the WAN type. A user can
only select Static IP, DHCP, PPPoE, L2TP, PPTP or DS-Lite.

Best regards,
Hans

---

From: Hans Liu <[email-masked]>
Date: Thu, 10 Nov 2011 12:28:03 +0800

On Wed, Nov 9, 2011 at 11:42 PM, Wes Beebee <[email-masked]> wrote:
>> an
>> configure one from the delegated prefix on “a virtual network intf (being
>> exactly what, loop ?)”.  If the delegated prefix <>64, I don’t see an
>> issue,

[Hans]: It is confusing. WAN.IPv6.12 of TR-124i2 is confusing too. CPE
device vendors may suffer from this kind of unclear requirements and
there may be differences and (maybe) IOT issues among implementations.

It says:  "If the device does not have a globally-scoped address on its
WAN interface after being delegated a prefix, it MUST create
addresses for itself from the delegated prefix. It MUST have at
least one address and MAY have more. There is currently no
algorithm defined for address creation and it should be assumed
that different service providers will want different rules for how to
create the address, how many addresses to create, and, in the
case of multiple addresses, how the different addresses are
used."

>
> - Wes
> _______________________________________________
> 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: Thu, 10 Nov 2011 09:07:49 +0100

Hi Wes,

Some remarks on your below comment.
You read the WAA-8 as: sent the /64 Pd to the LAN host and fetch one /128 from it for the loop intf

First of all, I think the WAA-8 is not clear on this.  In fact, as Ole pointed out, is was first written from the point-of-view that the ia_pd would be different from 64.  This will lead to different people translating this differently, hence different implementations by CPE vendors.

Secondly, I think you're violating the rules a little here.  You fetch a /128 host IP form the single available ia_pd and assign this one to the loopback interface and you assume that the DAD process works ok, i.e., that the CPE will say it is in use.  But, the loopback interface is no part of your LAN subnet, hence this will not work without an ND proxy (as Lorenzo mentions in his reply), unless the loop intf is 'bridged' into your LAN, which is not the case normally I'd say.

I think indeed it can work in Lorenzo's story, with the ND proxy, however. This will impose the need for some daemon to add this Proxy ND message automatically, as this is targeting residential gateways as well, meaning that manual intervention on this might not be possible/wanted.

Looking at these, I'm still convinced this topic  needs a more detailed description in the case of prefix-length = 64.  3 possibilities:

1.       The ia_pd gets sent to the Lan hosts, no address on loop available

è Will work fine for the hosts, but not remotely manageable

2.        The ia_pd gets sent fully to the loop, so loop gets an address from it, either /64 or /128 host-IP.   In this case, the Lan hosts will have no global IP, hence cannot get passed their local link or ULA territory, whatever available.

3.       Define Lorenzo's approach, using a ND proxy.

regs

Carl Wuyts

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: woensdag 9 november 2011 21:37
To: Wuyts Carl
Cc: [email-masked]
Subject: Re: [v6ops] RFC6204bis-02

On Wed, Nov 9, 2011 at 01:21, Wuyts Carl <[email-masked]<mailto:[email-masked]>> wrote:

I assume this is describing the situation where the WAN intf does not get an IPv6 addr (not via RA, not via dhcpv6 ia_na).  In this situation, you want to configure one from the delegated prefix on "a virtual network intf (being exactly what, loop ?)".  If the delegated prefix <>64, I don't see an issue, however, if the ia_pd prefix length = 64, this would mean that only the CPE would get an IPv6 address from the ia_pd, and nothing more left to distribute on the LAN OR the only available /64 gets sent to the LAN hosts, but nothing available on the CPE (for remote management).
No, wait. The CE router gets at least one /64 from PD, possibly more. If it doesn't have an IPv6 address (from RA, or from DHCPv6 NA) on the WAN interface, it picks ONE global address from the PD as its global IPv6 address. Since the CE router is a router that's connected to at least one /64 in the PD, it can just pick an autoconf address from one of those /64s, assign it to a loopback, and do proxy ND for it on the interface that "owns" that /64. DAD will take care of it. No?

---

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

Lorenzo,

About the link/no-link of RA and DHCPv6.
Interesting comments and some valid points, but it does not cover for the 100% of use cases I think.

First of all, our CPE is able to handle both scenario's, link the DHCPv6 client to RA or not, and act upon it.  So from that point-of-view, I'm not concerned to not be able to do this or anything, we support both.
However, a few things are being overlooked I think:

1.       In case of ptp WAN link, the customer might not want to sent any RA's at all, afterall, it is point-to-point, hence you cannot link DHCPv6 to the RA, as ... nothing will happen then.

2.       The DHCP WG is working on the options to get specific routes from the server, similar as for IPv4, hence there is no default route issue in that scenario, the route info will come from DHCPv6 in this case, not from RA.

Wrt the issue on CPE asking too often for PD, I agree this can be an issue.  In fact, on this the DHCP WG is also exchanging quite a few mails this week, so we might see some changes here, but are bound to the existing RFC today of course.

regs

Carl Wuyts

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: woensdag 9 november 2011 23:23
To: Wes Beebee
Cc: Wuyts Carl; [email-masked]
Subject: Re: [v6ops] RFC6204bis-02

I didn't make any suggestions in this thread. That discussion is being carried out elsewhere with a more limited group of people, because we don't necessarily want to spam the whole of v6ops with it :-)

All I did was give one important reason why it's not automatically a good idea to make RS and DHCPv6 PD independent.

Another good reason, which I just realize I forgot to mention, is that from the perspective of a CE router, having a DHCPv6 PD and no default route is pointless, because it can't go anywhere anyway. It's also harmful to the hosts behind it, because even if the CE router is implemented correctly and does not give the hosts a default route, it will still be giving them global IPv6 addresses, which will double their DNS lookup latency (because once they have a global IPv6 address, they will start asking for AAAA records).

I, for one, believe that the issue is really an access concentrator issue, which routinely manages congestion-control and rate-limits DHCPv6 packets ANYWAY.  It has to - to
protect the DHCPv6 servers from DoS attacks from untrusted CPE routers.

Because every time you rate-limit a DHCP request, that could be a user that can't get online. If you're hitting rate-limits all the time, you're denying service to real users all the time.

The problem here is not that one particular CE router asks for DHCP PD too often - it may be fine for one CE router to make 5 DHCPv6 requests in one minute, as long as it doesn't happen all the time. It's that when when you add up millions of CE routers asking every 2 minutes, *all the time* the aggregate load becomes very large.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 10 Nov 2011 09:37:46 +0100 (CET)

On Thu, 10 Nov 2011, Wuyts Carl wrote:

> (as Lorenzo mentions in his reply), unless the loop intf is 'bridged' 
> into your LAN, which is not the case normally I'd say.

I think some of us are "damaged" from the old cisco style of doing this, 
which would be:

int lan0
ipv6 address dhcpv6pd-space ::1/64

int loopback0
ipv6 unnumbered lan0

So basically this would work by lan0 always being "up" (regardless if 
there is a cable in there or not), the CPE will assign itself ::1 on that 
/64 which it got by DHCPv6-PD, and then it'll use that same address on 
loopback0, and one can do:

ip telnet source-interface Loopback0
ip tacacs source-interface Loopback0
logging source-interface Loopback0

etc. Everything the router sources itself will be sourced from the IP on 
Looopback0 which will be the address it has on lan0.

This has worked fine for 15-20 years on Cisco routers, I guess the 
confusion is from this model not being defined in an RFC?

> I think indeed it can work in Lorenzo's story, with the ND proxy, 
> however. This will impose the need for some daemon to add this Proxy ND 
> message automatically, as this is targeting residential gateways as 
> well, meaning that manual intervention on this might not be 
> possible/wanted.

I don't really see a need for ND proxy. Why is it needed?

> è Will work fine for the hosts, but not remotely manageable

It's still reachable, both from WAN and LAN. It's just the weak host model 
in standard operation.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 10 Nov 2011 09:40:46 +0100 (CET)

> ipv6 address dhcpv6pd-space ::1/64

This should be "ipv6 address unnumbered lan0".

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 10 Nov 2011 10:00:22 +0100

Although I've worked @ Cisco for a couple of years, I don't think I'm damaged by their "style", or any other style :-)
The CLI on our devices is very different from the one @ Cisco.

We don't do unnumbered loopback for the Lan interface, so the lan intf gets just an IPv6 address from the PD.  You could unnumber both sides, and indeed make the address reachable from both LAN/WAN, however I'm not sure this is the model you'd like to use on a residential CPE, i.e. use the same prefix on both BNG-CPE link as on CPE-LAN.

regs

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 10 Nov 2011 10:07:32 +0100 (CET)

On Thu, 10 Nov 2011, Wuyts Carl wrote:

> We don't do unnumbered loopback for the Lan interface, so the lan intf 
> gets just an IPv6 address from the PD.  You could unnumber both sides, 
> and indeed make the address reachable from both LAN/WAN, however I'm not 
> sure this is the model you'd like to use on a residential CPE, i.e. use 
> the same prefix on both BNG-CPE link as on CPE-LAN.

Why would the address be reachable from WAN using ND? The BNG already has 
a static route pointing to the CPE LL address that encompasses the whole 
DHCPv6-PD prefix, I don't understand why it would need to reach the 
address using ND on the WAN link.

I advocate to not have any GUA address at all on the WAN link, and that 
the CPE uses its address on the CPE lan interface for any locally sourced 
traffic (and I'm ok if this interface is always up from CPE point of view, 
regardless if there are any LAN ports that are up).

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 10 Nov 2011 10:18:55 +0100

I've no problem not assigning a GUA to the WAN intf itself, it's configurable, depends on the ISP's choice, so that's ok, we're very flexible in that area.  Sourcing host-originated traffic from our CPE indeed can use the GUA from the LAN, loop or WAN, no problem either, but I'm not sure our customers (i.e. ISPs/Telcos) would want to use an IP from a delegated prefix to be used as target IPv6 address for their remote management, in the CPE case, this is often CWMP.

Still, the idea of my message is not to say what should/must be done wrt GUA usage on LAN/WAN/loop, but rather to have a clear description of it in the RFC6204(bis), especially for the prefixlength=64 use case.

Carl Wuyts

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: donderdag 10 november 2011 10:08
To: Wuyts Carl
Cc: [email-masked]
Subject: RE: [v6ops] RFC6204bis-02

On Thu, 10 Nov 2011, Wuyts Carl wrote:

> and indeed make the address reachable from both LAN/WAN, however I'm 
> not sure this is the model you'd like to use on a residential CPE, 
> i.e. use the same prefix on both BNG-CPE link as on CPE-LAN.

Why would the address be reachable from WAN using ND? The BNG already has a static route pointing to the CPE LL address that encompasses the whole DHCPv6-PD prefix, I don't understand why it would need to reach the address using ND on the WAN link.

I advocate to not have any GUA address at all on the WAN link, and that the CPE uses its address on the CPE lan interface for any locally sourced traffic (and I'm ok if this interface is always up from CPE point of view, regardless if there are any LAN ports that are up).

---

From: Ole Troan <[email-masked]>
Date: Thu, 10 Nov 2011 12:58:42 +0100

Carl et al,

> Looking at these, I’m still convinced this topic  needs a more detailed description in the case of prefix-length = 64.  3 possibilities:
> 3.       Define Lorenzo’s approach, using a ND proxy.

4. The delegated prefix is used to assign a prefix to the LAN side interface. The CE assigns one address out of the /64 to the LAN
   interface.

no ND proxy needed. the only change is that the reference to an internal virtual interface in the requirement should be removed or made optional. possibly with text suggesting that if possible (PD size > 64) an internal always up interface should be used to allow for remote management even when the LAN side interface(s) are down.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 10 Nov 2011 13:00:45 +0100

Mikael,

>> (as Lorenzo mentions in his reply), unless the loop intf is 'bridged' into your LAN, which is not the case normally I'd say.
> 
> I think some of us are "damaged" from the old cisco style of doing this, which would be:
> 
> int lan0
> So basically this would work by lan0 always being "up" (regardless if there is a cable in there or not), the CPE will assign itself ::1 on that /64 which it got by DHCPv6-PD, and then it'll use that same address on loopback0, and one can do:
> 
> etc. Everything the router sources itself will be sourced from the IP on Looopback0 which will be the address it has on lan0.
> 
> This has worked fine for 15-20 years on Cisco routers, I guess the confusion is from this model not being defined in an RFC?

you may think you are damaged by the old cisco style of doing it, while you are in fact wrong. ;-)
the "ipv6 unnumbered" command does not do what its "ip unnumbered" equivalent does.
it is only a reference used by the source address selection algorithm. in the above configuration the address is bound to the lan0 interface. and therefore no form of ND proxy is needed.

cheers,
Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 10 Nov 2011 13:05:18 +0100 (CET)

On Thu, 10 Nov 2011, Ole Troan wrote:

> it is only a reference used by the source address selection algorithm. 
> in the above configuration the address is bound to the lan0 interface. 
> and therefore no form of ND proxy is needed.

I never said ND proxy was needed, I was advocating that it wasn't needed.

Also, I don't understand why you say it's different from the IPv4 
equivalent, in what way?

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 10 Nov 2011 13:06:45 +0100

Agree

Carl Wuyts

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: donderdag 10 november 2011 12:59
To: Wuyts Carl
Cc: Wes Beebee; [email-masked]
Subject: Re: [v6ops] RFC6204bis-02

Carl et al,

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 10 Nov 2011 13:09:31 +0100

Mikael,

> I never said ND proxy was needed, I was advocating that it wasn't needed.

indeed. I tried to say the same thing.

> Also, I don't understand why you say it's different from the IPv4 equivalent, in what way?

we're getting very cisco-ish here. ip unnumbered borrows an address from another interface. basically sharing an address between two interfaces. the IPv6 equivalent does no such thing. trust me, I wrote that code.

cheers,
Ole

---

From: François-Xavier Le Bail <[email-masked]>
Date: Thu, 10 Nov 2011 07:44:48 -0800 (PST)

________________________________
>From: Wuyts Carl <[email-masked]>
>To: Wes Beebee <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Sent: Thursday, November 10, 2011 9:07 AM
>Secondly, I think you’re violating the rules a little here.  You fetch a /128 host IP form the single available ia_pd and assign this one to the loopback interface and you assume that the DAD process works ok, i.e., that the CPE will say it is in use.  But, the loopback interface is no part of your LAN subnet, hence this will not work without an ND proxy (as Lorenzo mentions in his reply), unless the loop intf is ‘bridged’ into your LAN, which is not the case normally I’d say.
> 
>I think indeed it can work in Lorenzo’s story, with the ND proxy, however. This will impose the need for some daemon to add this Proxy ND message automatically, as this is targeting residential gateways as well, meaning that manual intervention on this might not be possible/wanted.
> 
>èWill work fine for the hosts, but not remotely manageable 

Hi,

Many CPE have a bridge on the LAN side, bridging Ethernet interfaces, Wifi interface, etc.

This bridge should be always up, not dependent of the underlying interfaces.

If you set on the bridge an EUI-64 (on other) based on the IA_PD, you dont need loopback, so no problem.

As said in RFC6204,  

WAA-9:  As a router, the IPv6 CE router MUST follow the weak host (Weak ES) model [RFC1122].  When originating packets from an interface, it will use a source address from another one of its interfaces if the outgoing interface does not have an address of suitable scope. 
Cheers,

François-Xavier

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 10 Nov 2011 13:51:11 -0800

On Thu, Nov 10, 2011 at 00:07, Wuyts Carl <[email-masked]>wrote:

> You read the WAA-8 as: sent the /64 Pd to the LAN host and fetch one /128
> from it for the loop intf****
>
> ** **
>
> First of all, I think the WAA-8 is not clear on this.  In fact, as Ole
> pointed out, is was first written from the point-of-view that the ia_pd
> would be different from 64.  This will lead to different people translating
> this differently, hence different implementations by CPE vendors.****
>
> ** **
>
> Secondly, I think you’re violating the rules a little here.  You fetch a
> /128 host IP form the single available ia_pd and assign this one to the
> loopback interface and you assume that the DAD process works ok, i.e., that
> the CPE will say it is in use.  But, the loopback interface is no part of
> your LAN subnet, hence this will not work without an ND proxy (as Lorenzo
> mentions in his reply), unless the loop intf is ‘bridged’ into your LAN,
> which is not the case normally I’d say.
>

Actually, I think that in practice this is not a problem, because the LAN
interface is actually a bridge, so it's a virtual interface. So you can
simply assign the address to it and you're done.

As an example: say that you have a /64 for the LAN interface:
2001:db8:0:1::/64 . That's a virtual interface, so you can just pick any
address on the LAN interface (say 2001:db8:0:1:<IID>/64, or even
2001:db8:0:1::1) , and assign it to the LAN interface, and that's it. DAD
will work.

I agree that the text needs to be clarified.

What was the original reason for saying "configuring it on one of its
internal virtual interfaces"? Was it just to say that the CE router should
be able to use a LAN-side address when talking to the rest of the world? I
think the weak host model (mandated in WAA-9) does that for you. So perhaps
we can just change the text to "MUST create global IPv6 address(es) from
its delegated prefix(es) to use for global communications", and leave it at
that?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 10 Nov 2011 14:42:11 -0800

On Thu, Nov 10, 2011 at 00:15, Wuyts Carl <[email-masked]>wrote:

> 1.       **In case of ptp WAN link, the customer might not want to sent
> any RA’s at all, afterall, it is point-to-point, hence you cannot link
> DHCPv6 to the RA, as … nothing will happen then.
>

What kind of point-to-point link? In PPP you have IPv6CP and you can use
that as a signal to trigger DHCPv6 PD. Are there other kinds?

> ****
>
> **2.       **The DHCP WG is working on the options to get specific routes
> from the server, similar as for IPv4, hence there is no default route issue
> in that scenario, the route info will come from DHCPv6 in this case, not
> from RA.
>
People have been talking about getting routes via DHCPv6 for a long time,
and it hasn't actually happened yet. If this time the IETF does reach
consensus on it and it becomes an RFC, then that RFC can always update this
one.

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 11 Nov 2011 13:19:01 +0100

Lorenzo,

PPP indeed is a good example, and yes, IPVPv6 could potentially trigger DHCPv6 PD, but no, this is not a good idea.  It's remarkable to see/hear always: "CPE not ready", "CPE the issue in IPV6", but it keeps coming back to the CPE having to adapt.  You suggest to listen to IPCPv6, possible of course, but yet again another mechanism ??  Listen to RA for auto-injection of the default route is ok and commonly agreed upon, in fact, we support it, but we also support to ignore them, CPE must be flexible, but your suggestion now is to listen to IPCPv6 and then linking it to DHCP-PD ?  So no, no hard req needed to link DHCP-PD to RAS listening, not ok for e.g. PPP.

And no, please do not start linking up other protocols please, it is not necessary and only creates extra possibilities.  On one hand, everyone expects the CPE do be nearly free-of-charge, but on the other hand it must be capable of supporting all kind of scenario's ?!

What's next ??

I agree on the more-specific routes.  Indeed it's ongoing for some time, but not yet really materialized, on the other hand, it'll come sooner or later so better take it into account today in describing standard CPE behavior.

regs

Carl Wuyts

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: donderdag 10 november 2011 23:42
To: Wuyts Carl
Cc: Wes Beebee; [email-masked]
Subject: Re: [v6ops] RFC6204bis-02

On Thu, Nov 10, 2011 at 00:15, Wuyts Carl <[email-masked]<mailto:[email-masked]>> wrote:
1.       In case of ptp WAN link, the customer might not want to sent any RA's at all, afterall, it is point-to-point, hence you cannot link DHCPv6 to the RA, as ... nothing will happen then.

What kind of point-to-point link? In PPP you have IPv6CP and you can use that as a signal to trigger DHCPv6 PD. Are there other kinds?

2.       The DHCP WG is working on the options to get specific routes from the server, similar as for IPv4, hence there is no default route issue in that scenario, the route info will come from DHCPv6 in this case, not from RA.
People have been talking about getting routes via DHCPv6 for a long time, and it hasn't actually happened yet. If this time the IETF does reach consensus on it and it becomes an RFC, then that RFC can always update this one.

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 11 Nov 2011 13:21:17 +0100

Agreed, but it's all about what people understand as "virtual intf".  I'd link it to the loop, in this case, "another subnet" compared to the LAN, so not a good idea to use /128 from same prefix.

I agree with your changed description below on, avoids misinterpretation for sure.

regs

Carl Wuyts

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: donderdag 10 november 2011 22:51
To: Wuyts Carl
Cc: Wes Beebee; [email-masked]
Subject: Re: [v6ops] RFC6204bis-02

On Thu, Nov 10, 2011 at 00:07, Wuyts Carl <[email-masked]<mailto:[email-masked]>> wrote:
Some remarks on your below comment.
You read the WAA-8 as: sent the /64 Pd to the LAN host and fetch one /128 from it for the loop intf

Actually, I think that in practice this is not a problem, because the LAN interface is actually a bridge, so it's a virtual interface. So you can simply assign the address to it and you're done.

As an example: say that you have a /64 for the LAN interface: 2001:db8:0:1::/64 . That's a virtual interface, so you can just pick any address on the LAN interface (say 2001:db8:0:1:<IID>/64, or even 2001:db8:0:1::1) , and assign it to the LAN interface, and that's it. DAD will work.

What was the original reason for saying "configuring it on one of its internal virtual interfaces"? Was it just to say that the CE router should be able to use a LAN-side address when talking to the rest of the world? I think the weak host model (mandated in WAA-9) does that for you. So perhaps we can just change the text to "MUST create global IPv6 address(es) from its delegated prefix(es) to use for global communications", and leave it at that?

---

From: Wes Beebee <[email-masked]>
Date: Fri, 11 Nov 2011 09:30:38 -0500

>> but we also support to ignore them, CPE must be flexible, but your suggestion
>> now is to listen to IPCPv6 and then linking it to DHCP-PD ?  So no, no hard
>> req needed to link DHCP-PD to RAS listening, not ok for e.g. PPP.
>  
>> And no, please do not start linking up other protocols please, it is not
>> necessary and only creates extra possibilities.  On one hand, everyone
>> expects the CPE do be nearly free-of-charge, but on the other hand it must be
>> capable of supporting all kind of scenario¹s ?!
>  
>> What¹s next ??

+1 

Lorenzo -

All this thrashing is accomplishing only one thing - confusion.

We need to send clear signals in RFC6204bis to CPE vendors.

Where we were not clear in RFC 6204, we need to be more clear in RFC
6204bis.  However, this is not an opportunity to revisit solutions that are
already Pareto optimal.

Pareto optimal does not mean that everyone is happy - it simply means that
you can't make someone happy without making someone else unhappy.

- Wes

---

From: james woodyatt <[email-masked]>
Date: Fri, 11 Nov 2011 10:41:57 -0800

On Nov 11, 2011, at 06:30 , Wes Beebee wrote:
> 
> However, this is not an opportunity to revisit solutions that are
> already Pareto optimal.
> 

Then I propose to suspend all further IETF activity on IPv6 until the opportunity arises again to revisit solutions to the exhaustion of IPv4 free pool space via operating strategies other than NAT444.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Wes Beebee <[email-masked]>
Date: Fri, 11 Nov 2011 14:43:07 -0500

> Then I propose to suspend all further IETF activity on IPv6 until the
> opportunity arises again to revisit solutions to the exhaustion of IPv4 free
> pool space via operating strategies other than NAT444.

Then I propose that we spend the next 10 years arguing over the meaning of
the M and O bits so that we can achieve no more consensus than the previous
10 years have gotten us.

- Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 12 Nov 2011 01:21:56 -0600

Wuyts,

Sorry for the delayed reply.   The bullet is correct.  If a CPE router
WAN has a public IPv4 address, then the router can send data over the
native IPv4 network so why invoke DS-Lite?  As for your error related
comments/questions, please see the Coexistence section of the document
version -02.  See bullets 1 and 3 where a specific order is specified
and if the CE follows the order there is les chance of mistake.   

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

Thanks for the review.

Hemant

 

1.      DLW-4:  If the IPv6 CE Router is configured with a public IPv4
address on its WAN interface, where public IPv4 address is defined as
any address which is not in the private IP address space specified in
[RFC5735] and also not in the reserved IP address space specified in
[RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element.

This one is not fully ok I'd say.  First of all, the DSlite is supposed
to run on a v6-only intf, hence you could consider it as a configuration
issue in case you have configured a public  IPv4 on it ?  Even if not, I
don't see what you should have to check for public IPv4 address presence
to bring up (or not) the DSLite intf.

And then what happens if the DSLite tunnel is up, and a public IPv4 is
being configured on top ?  Bring it down ?

Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite.
This will bring up the DSLite intf, because of the option, why bothering
checking the public IPv4 presence ?

Maybe this is not really an issue, afterall, it's a configuration
"mistake".

---

From: Ole Troan <[email-masked]>
Date: Sat, 12 Nov 2011 11:32:18 +0100

Hemant,

> Sorry for the delayed reply.   The bullet is correct.  If a CPE router WAN has a public IPv4 address, then the router can send data over the native IPv4 network so why invoke DS-Lite?  As for your error related comments/questions, please see the Coexistence section of the document version -02.  See bullets 1 and 3 where a specific order is specified and if the CE follows the order there is les chance of mistake.   
>  

I think there are some fundamental differences in how CPEs are supposed to operate and be provisioned.

1) provision the CPE with _all_ information available in the network. including DS-lite DHCP options, 6rd DHCP options,
   native IPv6, native IPv4, whatever... and make the CPE intelligently choose what makes sense.

2) expect the CPE to follow what it is being told to do. meaning that it gets only provisioned with information that
   makes sense for it. everything else is a configuration error. if it gets provisioned with e.g both native IPv6 and 6rd,
   then it should use both connections as if it is multi-homed.

the scenario in 2 is important for the transitioning case between 6rd and native, likewise I think the same thing applies to ds-lite and the other shared IPv4 scenarios. I'm in camp 2, and I think the co-existence text in the draft is wrong. (I think Mark is working on a more complete text in a 6rd sunsetting draft, and we should probably ask the ds-lite authors to work through the DS-lite scenario as well).

cheers,
Ole

>  
> Thanks for the review.
>  
> Hemant
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Wuyts Carl
> This one is not fully ok I’d say.  First of all, the DSlite is supposed to run on a v6-only intf, hence you could consider it as a configuration issue in case you have configured a public  IPv4 on it ?  Even if not, I don’t see what you should have to check for public IPv4 address presence to bring up (or not) the DSLite intf.
> Maybe this is not really an issue, afterall, it’s a configuration “mistake”.
>

---

From: Hans Liu <[email-masked]>
Date: Sat, 12 Nov 2011 21:15:04 +0800

> the scenario in 2 is important for the transitioning case between 6rd and native, likewise I think the same thing applies to ds-lite and the other shared IPv4 scenarios. I'm in camp 2, and I think…

Agree with Ole on this.

Regards,
Hans

---

From: Mark Townsley <[email-masked]>
Date: Sat, 12 Nov 2011 14:18:54 +0100

> the scenario in 2 is important for the transitioning case between 6rd and native, likewise I think the same thing applies to ds-lite and the other shared IPv4 scenarios. I'm in camp 2, and I think…

Yes, I am, in conjunction with the 6rd experts at Free. You should see something very soon.

- Mark

---

From: Sander Steffann <[email-masked]>
Date: Sat, 12 Nov 2011 21:15:06 +0100

Hi Ole,

> the scenario in 2 is important for the transitioning case between 6rd and native, likewise I think the same thing applies to ds-lite and the other shared IPv4 scenarios. I'm in camp 2, and I think…

I agree fully. If we take migrations from one technology to another into account now we will make our (well, ISP / network operator) lives a *lot* easier in the future.

Met vriendelijke groet,
Sander Steffann

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 12 Nov 2011 19:48:31 -0600

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Saturday, November 12, 2011 5:32 AM
To: Hemant Singh (shemant)
Cc: Wuyts Carl; [email-masked]
Subject: Re: [v6ops] RFC6204bis-02

>2) expect the CPE to follow what it is being told to do. meaning that
it gets only provisioned with information that
>   makes sense for it. everything else is a configuration error. if it
gets provisioned with e.g both native IPv6 and 6rd,
>   then it should use both connections as if it is multi-homed.

Already specified in the Coexistence section for how does 6rd work with
native IPv6 - see bullet 5 of the -02 version posted.  Then the
sunsetting of 6rd to move to native IPv6 is discussed in a paragraph
below the bullets of the Coexistence section.

>the other shared IPv4 scenarios. I'm in camp 2, and I think the
co-existence text in the draft is wrong. 

What specifically is wrong?  During emails in Softwires in the past year
one Int area AD has already said the IPv6 CE router includes a
Coexistence section because someone asked how does the CE router know
how to start DS-Lite, vs. 6rd, vs. IPv4 or IPv6 native tech.  

Hemant

---

From: Mark Andrews <[email-masked]>
Date: Sun, 13 Nov 2011 18:00:05 +1100

In message <[email-masked]>, "He
mant Singh (shemant)" writes:
> and if the CE follows the order there is les chance of mistake.  =20
> 

Personally this is being over prescriptive.  Today we have CPE being
presented what appear to be public address but in practice are NAT'd
addresses.  If it is reasonable to run DS-lite with RFC 1918 addresses
on the WAN interface it is reasonable to run DS-lite with what
appear to be public addresses on the WAN interface.  It is also
reasonable to run DS-Lite on top of 6rd especially when the addresses
being used for 6rd are ambigious.  It really isn't that hard to get
the routing correct.  Yes, there is double encapsulation but the
payoff is a single NAT layer.

DS-Lite options learnt on the WAN interface SHOULD be made available
on the LAN interfaces even if there is no B4 functionality in the CPE.
This allows individual ipv6-only nodes to use DS-Lite.

> =20
> =20
> =20
> =20
> =20
> =20
> =20
> ------_=_NextPart_001_01CCA10B.C40327FE
> Content-Type: text/html;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
> xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
> xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
> xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
> xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
> http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 =
> (filtered medium)"><style><!--
> /* Font Definitions */
> @font-face
> 	{font-family:"Cambria Math";
> 	panose-1:2 4 5 3 5 4 6 3 2 4;}
> @font-face
> 	{font-family:Calibri;
> 	panose-1:2 15 5 2 2 2 4 3 2 4;}
> @font-face
> 	{font-family:Tahoma;
> 	panose-1:2 11 6 4 3 5 4 4 2 4;}
> @font-face
> 	{font-family:Consolas;
> 	panose-1:2 11 6 9 2 2 4 3 2 4;}
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:11.0pt;
> 	font-family:"Calibri","sans-serif";}
> a:link, span.MsoHyperlink
> 	{mso-style-priority:99;
> 	color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{mso-style-priority:99;
> 	color:purple;
> 	text-decoration:underline;}
> p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
> 	{mso-style-priority:99;
> 	mso-style-link:"Plain Text Char";
> 	margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:10.5pt;
> 	font-family:Consolas;}
> p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
> 	{mso-style-priority:99;
> 	mso-style-link:"Balloon Text Char";
> 	margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:8.0pt;
> 	font-family:"Tahoma","sans-serif";}
> p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
> 	{mso-style-priority:34;
> 	margin-top:0in;
> 	margin-right:0in;
> 	margin-bottom:0in;
> 	margin-left:.5in;
> 	margin-bottom:.0001pt;
> 	font-size:11.0pt;
> 	font-family:"Calibri","sans-serif";}
> span.PlainTextChar
> 	{mso-style-name:"Plain Text Char";
> 	mso-style-priority:99;
> 	mso-style-link:"Plain Text";
> 	font-family:Consolas;}
> span.BalloonTextChar
> 	{mso-style-name:"Balloon Text Char";
> 	mso-style-priority:99;
> 	mso-style-link:"Balloon Text";
> 	font-family:"Tahoma","sans-serif";}
> span.EmailStyle22
> 	{mso-style-type:personal;
> 	font-family:"Calibri","sans-serif";
> 	color:windowtext;}
> span.EmailStyle23
> 	{mso-style-type:personal-reply;
> 	font-family:"Calibri","sans-serif";
> 	color:#1F497D;}
> .MsoChpDefault
> 	{mso-style-type:export-only;
> 	font-size:10.0pt;}
> @page WordSection1
> 	{size:8.5in 11.0in;
> 	margin:1.0in 1.0in 1.0in 1.0in;}
> div.WordSection1
> 	{page:WordSection1;}
> /* List Definitions */
> @list l0
> 	{mso-list-id:1430270771;
> 	mso-list-type:hybrid;
> 	mso-list-template-ids:1983573538 67698703 67698713 67698715 67698703 =
> 67698713 67698715 67698703 67698713 67698715;}
> @list l0:level1
> 	{mso-level-tab-stop:none;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level2
> 	{mso-level-tab-stop:1.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level3
> 	{mso-level-tab-stop:1.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level4
> 	{mso-level-tab-stop:2.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level5
> 	{mso-level-tab-stop:2.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level6
> 	{mso-level-tab-stop:3.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level7
> 	{mso-level-tab-stop:3.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level8
> 	{mso-level-tab-stop:4.0in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> @list l0:level9
> 	{mso-level-tab-stop:4.5in;
> 	mso-level-number-position:left;
> 	text-indent:-.25in;}
> ol
> 	{margin-bottom:0in;}
> ul
> 	{margin-bottom:0in;}
> --></style><!--[if gte mso 9]><xml>
> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
> </xml><![endif]--><!--[if gte mso 9]><xml>
> <o:shapelayout v:ext=3D"edit">
> <o:idmap v:ext=3D"edit" data=3D"1" />
> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
> vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
> style=3D'color:#1F497D'>Wuyts,<o:p></o:p></span></p><p =
> class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
> class=3DMsoNormal><span style=3D'color:#1F497D'>Sorry for the delayed =
> reply.&nbsp;&nbsp; The bullet is correct.&nbsp; If a CPE router WAN has =
> a public IPv4 address, then the router can send data over the native =
> IPv4 network so why invoke DS-Lite?&nbsp; As for your error related =
> comments/questions, please see the Coexistence section of the document =
> version -02.&nbsp; See bullets 1 and 3 where a specific order is =
> specified and if the CE follows the order there is les chance of =
> mistake.&nbsp; &nbsp;<o:p></o:p></span></p><p class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
> class=3DMsoNormal><span style=3D'color:#1F497D'><a =
> href=3D"http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15">h=
> ttp://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15</a><o:p></o=
> :p></span></p><p class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
> class=3DMsoNormal><span style=3D'color:#1F497D'>Thanks for the =
> review.<o:p></o:p></span></p><p class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
> class=3DMsoNormal><span =
> style=3D'color:#1F497D'>Hemant<o:p></o:p></span></p><p =
> class=3DMsoNormal><span =
> style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div =
> style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
> 0in 0in'><p class=3DMsoNormal><b><span =
> style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
> </b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
> [email-masked] [mailto:[email-masked]] <b>On Behalf Of =
> </b>Wuyts Carl<br><b>Sent:</b> Wednesday, November 09, 2011 4:21 =
> AM<br><b>To:</b> [email-masked]<br><b>Subject:</b> [v6ops] =
> RFC6204bis-02<o:p></o:p></span></p></div></div><p =
> class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
> class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoListParagraph =
> style=3D'text-indent:-.25in;mso-list:l0 level1 lfo2'><![if =
> !supportLists]><b><span style=3D'mso-list:Ignore'>1.<span =
> style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
> </span></span></b><![endif]><b><u>DLW-4:&nbsp; If the IPv6 CE Router is =
> configured with a public IPv4 address on its WAN interface, where public =
> IPv4 address is defined as any address which is not in the private IP =
> address space specified in [RFC5735] and also not in the reserved IP =
> address space specified in [RFC6333], then the IPv6 CE Router MUST =
> disable the DS-Lite B4 element.<o:p></o:p></u></b></p><p =
> class=3DMsoPlainText><b><u><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p><span =
> style=3D'text-decoration:none'>&nbsp;</span></o:p></span></u></b></p><p =
> class=3DMsoPlainText><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
> </o:p></span></p><p class=3DMsoPlainText><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>This one =
> is not fully ok I&#8217;d say.&nbsp; First of all, the DSlite is =
> supposed to run on a v6-only intf, hence you could consider it as a =
> configuration issue in case you have configured a public&nbsp; IPv4 on =
> it ?&nbsp; Even if not, I don&#8217;t see what you should have to check =
> for public IPv4 address presence to bring up (or not) the DSLite =
> intf.<o:p></o:p></span></p><p class=3DMsoPlainText><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>And then =
> what happens if the DSLite tunnel is up, and a public IPv4 is being =
> configured on top ?&nbsp; Bring it down ?<o:p></o:p></span></p><p =
> class=3DMsoPlainText><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Imagine =
> you boot the CPE, preconfigured with DHCPv6 option for dslite.&nbsp; =
> This will bring up the DSLite intf, because of the option, why bothering =
> checking the public IPv4 presence ?<o:p></o:p></span></p><p =
> class=3DMsoPlainText><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Maybe this =
> is not really an issue, afterall, it&#8217;s a configuration =
> &#8220;mistake&#8221;.<o:p></o:p></span></p><p =
> class=3DMsoPlainText><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
> </o:p></span></p><p class=3DMsoPlainText><b><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>So my =
> recommendation here would be to remove this =
> requirement.<o:p></o:p></span></b></p><p class=3DMsoPlainText><span =
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;=
> </o:p></span></p><p =
> class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
> ------_=_NextPart_001_01CCA10B.C40327FE--
> 
> --===============8555349567329490546==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============8555349567329490546==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

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

Just a small Q.  What are you referring to exactly when stating:
""
DS-Lite options learnt on the WAN interface ...
""
DS-Lite options being ??? 

Carl Wuyts

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]] 
Sent: zondag 13 november 2011 8:00
To: Hemant Singh (shemant)
Cc: Wuyts Carl; [email-masked]
Subject: Re: [v6ops] RFC6204bis-02

> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15

Personally this is being over prescriptive.  Today we have CPE being presented what appear to be public address but in practice are NAT'd addresses.  If it is reasonable to run DS-lite with RFC 1918 addresses on the WAN interface it is reasonable to run DS-lite with what appear to be public addresses on the WAN interface.  It is also reasonable to run DS-Lite on top of 6rd especially when the addresses being used for 6rd are ambigious.  It really isn't that hard to get the routing correct.  Yes, there is double encapsulation but the payoff is a single NAT layer.

DS-Lite options learnt on the WAN interface SHOULD be made available on the LAN interfaces even if there is no B4 functionality in the CPE.
This allows individual ipv6-only nodes to use DS-Lite.

> This one is not fully ok I'd say.  First of all, the DSlite is 
> supposed to run on a v6-only intf, hence you could consider it as a 
> configuration issue in case you have configured a public  IPv4 on it ?  
> Even if not, I don't see what you should have to check for public IPv4 
> address presence to bring up (or not) the DSLite intf.
> 
> This will bring up the DSLite intf, because of the option, why 
> bothering checking the public IPv4 presence ?
> 
> charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 
> 12 = (filtered medium)"><style><!--
> /* Font Definitions */
> @font-face
> 67698713 67698715 67698703 67698713 67698715;} @list l0:level1
> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout 
> v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> 
> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US 
> link=3Dblue = vlink=3Dpurple><div class=3DWordSection1><p 
> class=3DMsoNormal><span style=3D'color:#1F497D'>Sorry for the delayed 
> = reply.&nbsp;&nbsp; The bullet is correct.&nbsp; If a CPE router WAN 
> has = a public IPv4 address, then the router can send data over the 
> native =
> = version -02.&nbsp; See bullets 1 and 3 where a specific order is = 
> mistake.&nbsp; &nbsp;<o:p></o:p></span></p><p class=3DMsoNormal><span 
> = style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p = 
> ttp://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15</a><o:p>
> </o= :p></span></p><p class=3DMsoNormal><span = 
> style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 
> = 0in 0in'><p class=3DMsoNormal><b><span = 
> style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</sp
> an>= </b><span 
> style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> = 
> [email-masked] [mailto:[email-masked]] <b>On Behalf Of 
> = </b>Wuyts Carl<br><b>Sent:</b> Wednesday, November 09, 2011 4:21 = 
> style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> = </span></span></b><![endif]><b><u>DLW-4:&nbsp; If the IPv6 CE Router 
> is = configured with a public IPv4 address on its WAN interface, where 
> public =
> IPv4 address is defined as any address which is not in the private IP 
> = address space specified in [RFC5735] and also not in the reserved IP 
> = address space specified in [RFC6333], then the IPv6 CE Router MUST = 
> style=3D'text-decoration:none'>&nbsp;</span></o:p></span></u></b></p><
> p = class=3DMsoPlainText><span = 
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nb
> sp;= </o:p></span></p><p class=3DMsoPlainText><span = 
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>This one 
> = is not fully ok I&#8217;d say.&nbsp; First of all, the DSlite is = 
> configuration issue in case you have configured a public&nbsp; IPv4 on 
> = it ?&nbsp; Even if not, I don&#8217;t see what you should have to 
> check = for public IPv4 address presence to bring up (or not) the 
> DSLite = intf.<o:p></o:p></span></p><p class=3DMsoPlainText><span = 
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>And then 
> = what happens if the DSLite tunnel is up, and a public IPv4 is being 
> = configured on top ?&nbsp; Bring it down ?<o:p></o:p></span></p><p = 
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Imagine 
> = you boot the CPE, preconfigured with DHCPv6 option for dslite.&nbsp; 
> = This will bring up the DSLite intf, because of the option, why 
> bothering = checking the public IPv4 presence 
> ?<o:p></o:p></span></p><p = class=3DMsoPlainText><span = 
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Maybe 
> this = is not really an issue, afterall, it&#8217;s a configuration = 
> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nb
> sp;= </o:p></span></p><p class=3DMsoPlainText><b><span =

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 14 Nov 2011 11:51:50 +0100

Well, Indeed, if a public v4 address is present, one could wonder why still bringing up the DSLite.  On the other hand, why not ?
Reason for mentioning this is that there are too many links created between things/protocols (e.g. the RA/DHCP which I was pointing at too in these emails).  We, as CPE vendor, are trying to be as much flexible to our audience as possible, so we can automatically create dslite tunnels etc.  Suppose you now first have to check the IPv4 public presence on the Wan intf )on which the tunnel is supposed to be mapped onto), then you've to introduce extra checks, while things, theoretically at least, can co-exist.  What will you do if someone adds an IPv4 public address on this same WAN intf AFTER the DSLite tunnel was created ?  Tear it down automatically (meaning you've to poll for the presence or make sure extra eventing is in place??)  So you introduce extra complexity when doing this, which in fact are not needed.

Carl Wuyts

From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: zaterdag 12 november 2011 8:22
To: Wuyts Carl; [email-masked]
Subject: RE: [v6ops] RFC6204bis-02

Wuyts,

Thanks for the review.

Hemant

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: Wednesday, November 09, 2011 4:21 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [v6ops] RFC6204bis-02

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Nov 2011 08:07:38 +1100

In message <[email-masked]>, Wuyts Carl w
rites:
> DS-Lite options being ???=20

I suppose it is more formally labeled the "The AFTR-Name DHCPv6 Option".

This should be able to be learnt from upstream, much the same way as DNS servers
can be learnt from upstream.

> Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium
> Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed=
> egem, Belgium
> Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe=
> n
> 
> From: Mark Andrews [mailto:[email-masked]]=20
> In message <[email-masked]>=
> , "He mant Singh (shemant)" writes:
> >
> > Wuyts,
> >=20
> > WAN has a public IPv4 address, then the router can send data over the=20
> > native IPv4 network so why invoke DS-Lite?  As for your error related=20
> > comments/questions, please see the Coexistence section of the document=20
> > version -02.  See bullets 1 and 3 where a specific order is specified=20
> > and if the CE follows the order there is les chance of mistake.  =3D20
> >=20
> Personally this is being over prescriptive.  Today we have CPE being presen=
> ted what appear to be public address but in practice are NAT'd addresses.  =
> If it is reasonable to run DS-lite with RFC 1918 addresses on the WAN inter=
> face it is reasonable to run DS-lite with what appear to be public addresse=
> s on the WAN interface.  It is also reasonable to run DS-Lite on top of 6rd=
>  especially when the addresses being used for 6rd are ambigious.  It really=
>  isn't that hard to get the routing correct.  Yes, there is double encapsul=
> ation but the payoff is a single NAT layer.
> 
> DS-Lite options learnt on the WAN interface SHOULD be made available on the=
>  LAN interfaces even if there is no B4 functionality in the CPE.
> > From: [email-masked] [mailto:[email-masked]] On Behalf=20
> > Of Wuyts Carl
> > =3D20
> > =3D20
> > address on its WAN interface, where public IPv4 address is defined as=20
> > any address which is not in the private IP address space specified in=20
> > [RFC5735] and also not in the reserved IP address space specified in=20
> > =3D20
> > =3D20
> > This one is not fully ok I'd say.  First of all, the DSlite is=20
> > supposed to run on a v6-only intf, hence you could consider it as a=20
> > configuration issue in case you have configured a public  IPv4 on it ? =20
> > Even if not, I don't see what you should have to check for public IPv4=20
> > And then what happens if the DSLite tunnel is up, and a public IPv4 is=20
> > This will bring up the DSLite intf, because of the option, why=20
> > Maybe this is not really an issue, afterall, it's a configuration=20
> > "mistake".
> >=20
> > =3D20
> >=20
> > =3D20
> > =3D20
> > ------_=3D_NextPart_001_01CCA10B.C40327FE
> > Content-Type: text/html;
> > 	charset=3D"us-ascii"
> > <html xmlns:v=3D3D"urn:schemas-microsoft-com:vml" =3D=20
> > xmlns:o=3D3D"urn:schemas-microsoft-com:office:office" =3D=20
> > xmlns:w=3D3D"urn:schemas-microsoft-com:office:word" =3D=20
> > xmlns:m=3D3D"http://schemas.microsoft.com/office/2004/12/omml" =3D=20
> > xmlns=3D3D"http://www.w3.org/TR/REC-html40"><head><meta =3D=20
> > http-equiv=3D3DContent-Type content=3D3D"text/html; =3D=20
> > charset=3D3Dus-ascii"><meta name=3D3DGenerator content=3D3D"Microsoft Wor=
> d=20
> > 12 =3D (filtered medium)"><style><!--
> > /* Font Definitions */
> > @font-face
> > 	mso-list-template-ids:1983573538 67698703 67698713 67698715 67698703=20
> > =3D
> > <o:shapedefaults v:ext=3D3D"edit" spidmax=3D3D"1026" />=20
> > </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout=20
> > v:ext=3D3D"edit"> <o:idmap v:ext=3D3D"edit" data=3D3D"1" />=20
> > </o:shapelayout></xml><![endif]--></head><body lang=3D3DEN-US=20
> > link=3D3Dblue =3D vlink=3D3Dpurple><div class=3D3DWordSection1><p=20
> > class=3D3DMsoNormal><span =3D=20
> > style=3D3D'color:#1F497D'>Wuyts,<o:p></o:p></span></p><p =3D=20
> > class=3D3DMsoNormal><span =3D=20
> > style=3D3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =3D=20
> > class=3D3DMsoNormal><span style=3D3D'color:#1F497D'>Sorry for the delayed=
> =20
> > =3D reply.&nbsp;&nbsp; The bullet is correct.&nbsp; If a CPE router WAN=20
> > has =3D a public IPv4 address, then the router can send data over the=20
> > native =3D
> > IPv4 network so why invoke DS-Lite?&nbsp; As for your error related =3D=20
> > comments/questions, please see the Coexistence section of the document=20
> > =3D version -02.&nbsp; See bullets 1 and 3 where a specific order is =3D=
> =20
> > specified and if the CE follows the order there is les chance of =3D=20
> > mistake.&nbsp; &nbsp;<o:p></o:p></span></p><p class=3D3DMsoNormal><span=20
> > =3D style=3D3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =3D=20
> > class=3D3DMsoNormal><span style=3D3D'color:#1F497D'><a =3D=20
> > href=3D3D"http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15
> > ">h=3D=20
> > </o=3D :p></span></p><p class=3D3DMsoNormal><span =3D=20
> > style=3D3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =3D=20
> > class=3D3DMsoNormal><span style=3D3D'color:#1F497D'>Thanks for the =3D=20
> > review.<o:p></o:p></span></p><p class=3D3DMsoNormal><span =3D=20
> > style=3D3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =3D=20
> > class=3D3DMsoNormal><span =3D=20
> > style=3D3D'color:#1F497D'>Hemant<o:p></o:p></span></p><p =3D=20
> > class=3D3DMsoNormal><span =3D=20
> > style=3D3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div =3D=20
> > style=3D3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in=20
> > =3D 0in 0in'><p class=3D3DMsoNormal><b><span =3D=20
> > style=3D3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</sp
> > an>=3D </b><span=20
> > style=3D3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =3D=20
> > [email-masked] [mailto:[email-masked]] <b>On Behalf Of=20
> > =3D </b>Wuyts Carl<br><b>Sent:</b> Wednesday, November 09, 2011 4:21 =3D=
> =20
> > AM<br><b>To:</b> [email-masked]<br><b>Subject:</b> [v6ops] =3D=20
> > RFC6204bis-02<o:p></o:p></span></p></div></div><p =3D=20
> > class=3D3DMsoNormal><o:p>&nbsp;</o:p></p><p =3D=20
> > class=3D3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3D3DMsoListParagraph =
> =3D
> > style=3D3D'text-indent:-.25in;mso-list:l0 level1 lfo2'><![if =3D=20
> > !supportLists]><b><span style=3D3D'mso-list:Ignore'>1.<span =3D=20
> > style=3D3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> > =3D </span></span></b><![endif]><b><u>DLW-4:&nbsp; If the IPv6 CE Router=
> =20
> > is =3D configured with a public IPv4 address on its WAN interface, where=
> =20
> > public =3D
> > IPv4 address is defined as any address which is not in the private IP=20
> > =3D address space specified in [RFC5735] and also not in the reserved IP=
> =20
> > =3D address space specified in [RFC6333], then the IPv6 CE Router MUST =
> =3D=20
> > disable the DS-Lite B4 element.<o:p></o:p></u></b></p><p =3D=20
> > class=3D3DMsoPlainText><b><u><span =3D=20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p><sp
> > an =3D=20
> > style=3D3D'text-decoration:none'>&nbsp;</span></o:p></span></u></b></p><
> > p =3D class=3D3DMsoPlainText><span =3D=20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nb
> > sp;=3D </o:p></span></p><p class=3D3DMsoPlainText><span =3D=20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>This one=
> =20
> > =3D is not fully ok I&#8217;d say.&nbsp; First of all, the DSlite is =3D=
> =20
> > supposed to run on a v6-only intf, hence you could consider it as a =3D=20
> > configuration issue in case you have configured a public&nbsp; IPv4 on=20
> > =3D it ?&nbsp; Even if not, I don&#8217;t see what you should have to=20
> > check =3D for public IPv4 address presence to bring up (or not) the=20
> > DSLite =3D intf.<o:p></o:p></span></p><p class=3D3DMsoPlainText><span =3D=
> =20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>And then=
> =20
> > =3D what happens if the DSLite tunnel is up, and a public IPv4 is being=20
> > =3D configured on top ?&nbsp; Bring it down ?<o:p></o:p></span></p><p =3D=
> =20
> > class=3D3DMsoPlainText><span =3D=20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Imagine=20
> > =3D you boot the CPE, preconfigured with DHCPv6 option for dslite.&nbsp;=
> =20
> > =3D This will bring up the DSLite intf, because of the option, why=20
> > bothering =3D checking the public IPv4 presence=20
> > ?<o:p></o:p></span></p><p =3D class=3D3DMsoPlainText><span =3D=20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Maybe=20
> > this =3D is not really an issue, afterall, it&#8217;s a configuration =3D=
> =20
> > &#8220;mistake&#8221;.<o:p></o:p></span></p><p =3D=20
> > class=3D3DMsoPlainText><span =3D=20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nb
> > sp;=3D </o:p></span></p><p class=3D3DMsoPlainText><b><span =3D=20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>So my =3D=
> =20
> > recommendation here would be to remove this =3D=20
> > requirement.<o:p></o:p></span></b></p><p class=3D3DMsoPlainText><span =3D=
> =20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nb
> > sp;=3D
> > </o:p></span></p><p =3D
> > class=3D3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
> > ------_=3D_NextPart_001_01CCA10B.C40327FE--
> >=20
> > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8555349567329490546=3D=3D
> > Content-Type: text/plain; charset=3D"us-ascii"
> > MIME-Version: 1.0
> > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8555349567329490546=3D=3D-=
> -
> --
> Mark Andrews, ISC

---

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

-----Original Message-----
From: Wuyts Carl [mailto:[email-masked]] 
Sent: Monday, November 14, 2011 6:19 PM
To: Mark Andrews; Hemant Singh (shemant)
Cc: [email-masked]
Subject: RE: [v6ops] RFC6204bis-02

>DS-Lite options being ??? 

IPv6 address of the AFTR element.

Hemant

---

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

From: Wuyts Carl [mailto:[email-masked]] 
Sent: Monday, November 14, 2011 6:52 PM
To: Hemant Singh (shemant); [email-masked]
Subject: RE: [v6ops] RFC6204bis-02

>Well, Indeed, if a public v4 address is present, one could wonder why
still bringing up the DSLite.  On the other hand, why not ?  

What use case do you have to run native IPv4 and DS-Lite concurrently?

>What will you do if someone adds an IPv4 public address on this same
WAN intf AFTER the DSLite tunnel was created ?  Tear it down
automatically (meaning you've to poll for the presence >or make sure
extra eventing is in place??)  So you introduce extra complexity when
doing this, which in fact are not needed.

This is sunsetting of DS-Lite which the document which is relatively
obvious.  If native IPv4 is provisioned when DS-Lite is running, the
DS-Lite tunnel has to be closed, and NAT44 services enabled on the CE
router with native IPv4.  Note NAT44 is not running when DS-Lite is
operational.  

Hemant

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Nov 2011 15:06:37 +1100

In message <[email-masked]>, "Hemant Singh (she
mant)" writes:
> 
> From: Wuyts Carl [mailto:[email-masked]]=20
> still bringing up the DSLite.  On the other hand, why not ? =20
> 
> =20
> 
 
You want to migrate from CGNv4/Public IPv4 to DS-Lite as you are
intending to stop supplying IPv4 addresses.  If you don't have
DS-Lite traffic you have no idea of whether you can do this or not.
This is especially true when you don't control the CPE devices.

"public v4 address" is a myth as far as the CPE is concerned.  It
has no way to know if it has a public IPv4 address or not.  I've
suggested DHCP options in the past to provide the information but
have been shot down as not needed.  6to4 needs,  DS-Lite vs CGN-64
needs it,  I'm sure other things will need it.

> operational. =20
> ------_=_NextPart_001_01CCA32D.D59BB1DD
> Content-Type: text/html;
> 	charset="us-ascii"
> span.EmailStyle24
> span.EmailStyle25
> Wuyts Carl [mailto:[email-masked]] <br><b>Sent:</b> Monday, =
> November 14, 2011 6:52 PM<br><b>To:</b> Hemant Singh (shemant); =
> [email-masked]<br><b>Subject:</b> RE: [v6ops] =
> class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal><span =
> style=3D'color:#1F497D'>&gt;Well, Indeed, if a public v4 address is =
> present, one could wonder why still bringing up the DSLite.&nbsp; On the =
> other hand, why not ?&nbsp; <o:p></o:p></span></p><p =
> class=3DMsoNormal><span style=3D'color:#1F497D'>What use case do you =
> have to run native IPv4 and DS-Lite =
> concurrently?<o:p></o:p></span></p><p class=3DMsoNormal><span =
> class=3DMsoNormal><span style=3D'color:#1F497D'>&gt;What will you do if =
> someone adds an IPv4 public address on this same WAN intf AFTER the =
> DSLite tunnel was created ?&nbsp; Tear it down automatically (meaning =
> you&#8217;ve to poll for the presence &gt;or make sure extra eventing is =
> in place??)&nbsp; So you introduce extra complexity when doing this, =
> which in fact are not needed.<o:p></o:p></span></p><p =
> class=3DMsoNormal><span style=3D'color:#1F497D'>This is sunsetting of =
> DS-Lite which the document which is relatively obvious.&nbsp; If native =
> IPv4 is provisioned when DS-Lite is running, the DS-Lite tunnel has to =
> be closed, and NAT44 services enabled on the CE router with native =
> IPv4.&nbsp; Note NAT44 is not running when DS-Lite is operational.&nbsp; =
> <o:p></o:p></span></p><p class=3DMsoNormal><span =
> style=3D'color:#1F497D'>Hemant<o:p></o:p></span></p></div></body></html>
> ------_=_NextPart_001_01CCA32D.D59BB1DD--
> 
> --===============7144896635156409313==
> --===============7144896635156409313==--

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 15 Nov 2011 13:39:59 +0800

On Nov 11, 2011 4:20 AM, "Wuyts Carl" <[email-masked]> wrote:
> PPP indeed is a good example, and yes, IPVPv6 could potentially trigger
DHCPv6 PD, but no, this is not a good idea.  It’s remarkable to see/hear
always: “CPE not ready”, “CPE the issue in IPV6”, but it keeps coming back
to the CPE having to adapt.  You suggest to listen to IPCPv6, possible of
course, but yet again another mechanism ??  Listen to RA for auto-injection
of the default route is ok and commonly agreed upon, in fact, we support
it, but we also support to ignore them, CPE must be flexible, but your
suggestion now is to listen to IPCPv6 and then linking it to DHCP-PD ?  So
no, no hard req needed to link DHCP-PD to RAS listening, not ok for e.g.
PPP.

Wait... so you're saying that your CPE starts DHCPv6 PD *before* IPv6CP is
up? How can you do that? You don't even have a link-local address.

What do you do on Ethernet links, start DHCPv6 PD before DAD completes, so
you can avoid tying the two protocols together?

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 15 Nov 2011 07:55:12 +0100

Ok, that's indeed the option I know off, but was not clear to me whether anything else was in scope.
Maybe this info must be provided to the LAN hosts, however, not sure how you see this ?

DHCPv6 in bridge mode from host, but then what with hosts not supporting DHCPv6 client (e.g. Win XP) ?
Use RA's to do this ? Not defined.
Other mechanisms ?  e.g. some "spoofing" scenario ?  In this case, it seems like yet again some extra functionality should be present in the CPE, shouldn't we first focus on the basics ??

Carl Wuyts

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]]
Sent: maandag 14 november 2011 22:08
To: Wuyts Carl
Cc: Hemant Singh (shemant); [email-masked]
Subject: Re: [v6ops] RFC6204bis-02

This should be able to be learnt from upstream, much the same way as DNS servers can be learnt from upstream.

> Technicolor Delivery Technologies Belgium NV Registered office
> (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem,
> Belgium Company registration number (ondernemingsnummer): 0428837295 -
> RPR Antwerpe= n
>
> In message
> <[email-masked]>=
> > WAN has a public IPv4 address, then the router can send data over
> >the=20  native IPv4 network so why invoke DS-Lite?  As for your error
> >related=20  comments/questions, please see the Coexistence section of
> >the document=20  version -02.  See bullets 1 and 3 where a specific
> >order is specified=20  and if the CE follows the order there is les
> >chance of mistake.  =3D20
> >=20
> presen= ted what appear to be public address but in practice are NAT'd
> addresses.  = If it is reasonable to run DS-lite with RFC 1918
> addresses on the WAN inter= face it is reasonable to run DS-lite with
> what appear to be public addresse= s on the WAN interface.  It is also
> reasonable to run DS-Lite on top of 6rd=  especially when the
> addresses being used for 6rd are ambigious.  It really=  isn't that
> hard to get the routing correct.  Yes, there is double encapsul= ation but the payoff is a single NAT layer.
>
> on the=  LAN interfaces even if there is no B4 functionality in the CPE.
> > From: [email-masked] [mailto:[email-masked]] On
> >Behalf=20  Of Wuyts Carl
> > address on its WAN interface, where public IPv4 address is defined
> >as=20  any address which is not in the private IP address space
> >specified in=20  [RFC5735] and also not in the reserved IP address
> >space specified in=20  [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element.
> >=20
> > =3D20
> >=20
> > =3D20
> >=20
> >supposed to run on a v6-only intf, hence you could consider it as
> >a=20  configuration issue in case you have configured a public  IPv4
> >on it ? =20  Even if not, I don't see what you should have to check
> >for public IPv4=20  address presence to bring up (or not) the DSLite intf.
> >=20
> > And then what happens if the DSLite tunnel is up, and a public IPv4
> >is=20  being configured on top ?  Bring it down ?
> >=20
> >     mso-list-template-ids:1983573538 67698703 67698713 67698715
> > 67698703=20 =3D
> > =3D reply.&nbsp;&nbsp; The bullet is correct.&nbsp; If a CPE router
> > WAN=20 has =3D a public IPv4 address, then the router can send data
> > over the=20 native =3D
> > IPv4 network so why invoke DS-Lite?&nbsp; As for your error related
> > =3D=20 comments/questions, please see the Coexistence section of the
> > document=20 =3D version -02.&nbsp; See bullets 1 and 3 where a
> > specific order is =3D=
> =20
> > specified and if the CE follows the order there is les chance of
> > =3D=20 mistake.&nbsp; &nbsp;<o:p></o:p></span></p><p
> > class=3D3DMsoNormal><span=20 =3D
> > ttp://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15</a><o:
> > p> </o=3D :p></span></p><p class=3D3DMsoNormal><span =3D=20
> > class=3D3DMsoNormal><span style=3D3D'color:#1F497D'>Thanks for the
> > =3D=20 review.<o:p></o:p></span></p><p class=3D3DMsoNormal><span
> > =3D=20 style=3D3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><p
> > =3D=20 class=3D3DMsoNormal><span =3D=20
> > style=3D3D'color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div
> > =3D=20 style=3D3D'border:none;border-top:solid #B5C4DF
> > 1.0pt;padding:3.0pt 0in=20 =3D 0in 0in'><p
> > class=3D3DMsoNormal><b><span =3D=20
> > style=3D3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
> > =3D=20 [email-masked] [mailto:[email-masked]] <b>On
> > Behalf Of=20 =3D </b>Wuyts Carl<br><b>Sent:</b> Wednesday, November
> > 09, 2011 4:21 =3D=
> =20
> > style=3D3D'font:7.0pt "Times New
> > Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> > IPv4 address is defined as any address which is not in the private
> > IP=20 =3D address space specified in [RFC5735] and also not in the
> > reserved IP=
> =20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p
> > ><sp
> > an =3D=20
> > style=3D3D'text-decoration:none'>&nbsp;</span></o:p></span></u></b><
> > /p>< p =3D class=3D3DMsoPlainText><span =3D=20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p
> > >&nb sp;=3D </o:p></span></p><p class=3D3DMsoPlainText><span =3D=20
> > =3D=20 configuration issue in case you have configured a
> > public&nbsp; IPv4 on=20 =3D it ?&nbsp; Even if not, I don&#8217;t
> > see what you should have to=20 check =3D for public IPv4 address
> > presence to bring up (or not) the=20 DSLite =3D
> > intf.<o:p></o:p></span></p><p class=3D3DMsoPlainText><span =3D=
> =20
> > =3D what happens if the DSLite tunnel is up, and a public IPv4 is
> > being=20 =3D configured on top ?&nbsp; Bring it down
> > ?<o:p></o:p></span></p><p =3D=
> =20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Imag
> > ine=20 =3D you boot the CPE, preconfigured with DHCPv6 option for
> > dslite.&nbsp;=
> =20
> > =3D This will bring up the DSLite intf, because of the option,
> > why=20 bothering =3D checking the public IPv4 presence=20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Mayb
> > e=20 this =3D is not really an issue, afterall, it&#8217;s a
> > configuration =3D=
> =20
> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p
> > >&nb sp;=3D </o:p></span></p><p class=3D3DMsoPlainText><b><span
> > =3D=20

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 15 Nov 2011 07:55:46 +0100

Sorry, but this option only foresees in AFTR name, so FQDN, no IPv6 address

Carl Wuyts

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: dinsdag 15 november 2011 1:31
To: Wuyts Carl; Mark Andrews
Cc: [email-masked]
Subject: RE: [v6ops] RFC6204bis-02

-----Original Message-----
From: Wuyts Carl [mailto:[email-masked]] 
Sent: Monday, November 14, 2011 6:19 PM
To: Mark Andrews; Hemant Singh (shemant)
Cc: [email-masked]
Subject: RE: [v6ops] RFC6204bis-02

Hemant

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 15 Nov 2011 08:03:23 +0100

inline

Carl Wuyts

From: Wuyts Carl [mailto:[email-masked]]
Sent: Monday, November 14, 2011 6:52 PM
To: Hemant Singh (shemant); [email-masked]<mailto:[email-masked]>
Subject: RE: [v6ops] RFC6204bis-02

What use case do you have to run native IPv4 and DS-Lite concurrently?
[Carl] multi-homed CPE, although they might use different WAN links.  Anyway, we cannot prevent that a customer is asking for this, some specific traffic routed and the other tunneled in DSLite

>What will you do if someone adds an IPv4 public address on this same WAN intf AFTER the DSLite tunnel was created ?  Tear it down automatically (meaning you've to poll for the presence >or make sure extra eventing is in place??)  So you introduce extra complexity when doing this, which in fact are not needed.

This is sunsetting of DS-Lite which the document which is relatively obvious.  If native IPv4 is provisioned when DS-Lite is running, the DS-Lite tunnel has to be closed, and NAT44 services enabled on the CE router with native IPv4.  Note NAT44 is not running when DS-Lite is operational.
[Carl] Still do not agree.  First of all, it should not be the task of the CPE to do all these things "auto-magically", secondly you can perfectly NAT some traffic while tunnel the other.  Again, some extra functionality is pushed onto the CPE, which should not be done.
Just an extra question: "Who is provisioning the public IPv4 on that WAN intf ?"  It's the ISP ? or the end-user ? or ... ?  If the ISP decides on doing this, he should be aware to remove either the tunnel or the DHCPv6 option to establish it at the same time, no ?  If not, you tell the CPe to request the DSLite AFTR, but it should then check public v4 on the intf to bring it up or not ?  Why asking the option then ?

Hemant

---

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

Carl Wuyts

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: dinsdag 15 november 2011 6:40
To: Wuyts Carl
Cc: [email-masked] WG; Wes Beebee
Subject: RE: [v6ops] RFC6204bis-02

> PPP indeed is a good example, and yes, IPVPv6 could potentially trigger DHCPv6 PD, but no, this is not a good idea.  It's remarkable to see/hear always: "CPE not ready", "CPE the issue in IPV6", bu…

Wait... so you're saying that your CPE starts DHCPv6 PD *before* IPv6CP is up? How can you do that? You don't even have a link-local address.

No, DHCPv6 runs on top of PPP in this case, hence it cannot start before it is up, but there's no link to RAs, which was the first statement: "link RA to DHCPv6", so no RA needed to start DHCPv6 on this link, hence preferably protocols should not be linked.

What do you do on Ethernet links, start DHCPv6 PD before DAD completes, so you can avoid tying the two protocols together?

We have different configuration possibilities here, one being not to listen to RA and configure the DHCPv6 client independent from the flags in it, so not wait for the RA indeed.  We're IPv6 ready logo certified, core protocols phase II, so don't worry, we respect the rules towards DAD and everything, we just don't want to tie up protocols, i.e. no fixed link between the RA and DHCPv6, no matter Ethernet, PPP or whatever

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Nov 2011 07:14:56 +0000

> DHCPv6 in bridge mode from host, but then what with hosts not supporting DHCPv6 client (e.g. Win XP) ?

We also fail on Win95 machines. Not sure how to address this...  :)

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 15 Nov 2011 08:17:42 +0100

:-)
Well, I don't know the situation in all countries but there's still a huge number of Win XPs around.  Doubt this will be the same for Win 95, or older ones like windows 3.1(1)

Carl Wuyts

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Nov 2011 07:25:15 +0000

> Well, I don't know the situation in all countries but there's still a huge number of Win XPs around.  Doubt this will be the same for Win 95, or older ones like windows 3.1(1)

True enough, but we shouldn't be designing protocols around ten year old operating systems. The trend should be for the market share of XP to decline over time.

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 15 Nov 2011 08:33:06 +0100

I agree, however, it's not me who has to agree.
Anyway, if you want to go more the up-to-date way: what about dhcpv6 client availability on mobile devices (smartphones etc)?

Carl Wuyts

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 01:55:10 -0600

> [Carl] multi-homed CPE, although they might use different WAN links.
Anyway, we cannot prevent that a customer is asking for this, some
specific traffic routed and the other tunneled in >DSLite

It's IPv4 multi-homed case and NAT44 that is out of the IPv6 CE router
document.  The rfc6204bis document also does not support multi-homing
except for the case of sunsetting 6rd.  See the Coexitence section's
last paragraph.

Hemant

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 15 Nov 2011 08:56:59 +0100

Ok, no problem to leave that out for me, approach remains the same however.  CPE should not have the task to automatically bring up/tear down the DSLite tunnel in case of "public" IPv4 presence.

Carl Wuyts

From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: dinsdag 15 november 2011 8:55
To: Wuyts Carl; [email-masked]
Subject: RE: [v6ops] RFC6204bis-02

> [Carl] multi-homed CPE, although they might use different WAN links.  Anyway, we cannot prevent that a customer is asking for this, some specific traffic routed and the other tunneled in >DSLite

It's IPv4 multi-homed case and NAT44 that is out of the IPv6 CE router document.  The rfc6204bis document also does not support multi-homing except for the case of sunsetting 6rd.  See the Coexitence section's last paragraph.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 02:34:39 -0600

From: Wuyts Carl [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2011 3:57 PM
To: Hemant Singh (shemant); [email-masked]
Subject: RE: [v6ops] RFC6204bis-02

> CPE should not have the task to automatically bring up/tear down the
DSLite tunnel in case of "public" IPv4 presence.

RfC6204bis document does not mention any such behavior mentioned above.
Please also note from the Coexistence section, the text says "Some
guidelines follow:".   A vendor is welcome to implement anything else
they'd like.  

Thanks,

Hemant

---

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

Ok, just want to make sure, as RFC6204 gets lots of interests lately in CPE area (but also e.g. @ RIPE), to not miss out on anything here.
The RFC6204bis says, quoted form it:
""
If the IPv6 CE Router is configured with a public IPv4
           address on its WAN interface, where public IPv4 address is
           defined as any address which is not in the private IP address
           space specified in [RFC5735<http://tools.ietf.org/html/rfc5735>] and also not in the reserved IP
           address space specified in [RFC6333<http://tools.ietf.org/html/rfc6333>], then the IPv6 CE Router
           MUST disable the DS-Lite B4 element.
""

MUST, so imho, the MUST should be replaced with MAY (or maybe SHOULD).

Carl Wuyts

From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: dinsdag 15 november 2011 9:35
To: Wuyts Carl; [email-masked]
Subject: RE: [v6ops] RFC6204bis-02

> CPE should not have the task to automatically bring up/tear down the DSLite tunnel in case of "public" IPv4 presence.

RfC6204bis document does not mention any such behavior mentioned above.   Please also note from the Coexistence section, the text says "Some guidelines follow:".   A vendor is welcome to implement anything else they'd like.

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Nov 2011 02:49:04 -0600

One author (cced in this email) of the DS-Lite RFC was agreeable to this
bullet.   I will ask him if he is OK with changing the MUST to a SHOULD
and then we can consider the change.

Thanks,

Hemant

From: Wuyts Carl [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2011 4:41 PM
To: Hemant Singh (shemant); [email-masked]
Subject: RE: [v6ops] RFC6204bis-02

Ok, just want to make sure, as RFC6204 gets lots of interests lately in
CPE area (but also e.g. @ RIPE), to not miss out on anything here.

""

           space specified in [RFC5735
<http://tools.ietf.org/html/rfc5735> ] and also not in the reserved IP

           address space specified in [RFC6333
<http://tools.ietf.org/html/rfc6333> ], then the IPv6 CE Router

""

---

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

Thank you, much appreciated

Carl Wuyts

From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: dinsdag 15 november 2011 9:49
To: Wuyts Carl; [email-masked]
Cc: Lee, Yiu
Subject: RE: [v6ops] RFC6204bis-02

One author (cced in this email) of the DS-Lite RFC was agreeable to this bullet.   I will ask him if he is OK with changing the MUST to a SHOULD and then we can consider the change.

Thanks,

Hemant

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 15 Nov 2011 11:58:47 +0100

Well, as I've said before, it's probably unlikely that you're using a DSLite together with a public IPv4 address, however, it is possible.  Moreover, I'm speaking as CPE vendor, the CPE should not be in charge of checking for "public IPv4 presence and based upon that tear up/bring down the DSLite tunnel.  If the ISP (we're not present in retail) decides on configuring the CPE with a public IPv4, then he should be aware of his actions and remove either the tunnel or the DHCPv6 option for the tunnel from the configuration.

The only thing I want is to have a common approach for ALL CPEs, not being enforced to start polling/eventing this, and increase complexity, so I just want to have this requirement in the RFC6204bis being present as MAY/SHOULD i.s.o. MUST.

Tx and regs

Carl Wuyts

From: Lee, Yiu [mailto:[email-masked]]
Sent: dinsdag 15 november 2011 11:48
To: Hemant Singh (shemant)
Cc: Wuyts Carl; [email-masked]
Subject: Re: [v6ops] RFC6204bis-02

Hi,

Could anybody please explain a scenario where an IPv4 address was given to a CPE but still want dslite? I assume the CPE would use the provisioned IPv4 address to access IPv4 service.
Thanks,
Yiu

On Nov 15, 2011, at 5:34 AM, "Hemant Singh (shemant)" <[email-masked]<mailto:[email-masked]>> wrote:
One author (cced in this email) of the DS-Lite RFC was agreeable to this bullet.   I will ask him if he is OK with changing the MUST to a SHOULD and then we can consider the change.

Thanks,

Hemant

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 15 Nov 2011 10:47:43 +0000

Hi,

Thanks,
Yiu

Thanks,

Hemant

“”
“”

---

From: <[email-masked]>
Date: Tue, 15 Nov 2011 14:28:14 +0100

Some providers might deploy IPv6-only access networks in order to be future proof and additionally reduce network complexity of Dual-Stack.
Regards
                Olaf

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Lee, Yiu
Gesendet: Dienstag, 15. November 2011 11:48
An: Hemant Singh (shemant)
Cc: [email-masked]
Betreff: Re: [v6ops] RFC6204bis-02

Hi,

Thanks,

Hemant

---

From: Ole Troan <[email-masked]>
Date: Tue, 15 Nov 2011 21:27:32 +0800

> Could anybody please explain a scenario where an IPv4 address was given to a CPE but still want dslite? I assume the CPE would use the provisioned IPv4 address to access IPv4 service.

walled garden native IPv4 address, Internet service over DS-lite. 
transitioning from one to the other. e.g from native IPv4 or from private native IPv4 (behind CGN) to DS-lite
see an example in the new 6rd-sunsetting draft for how native and tunneled service works.

this is really policy. something that we shouldn't encode here in an RFC.
if the CPE gets IPv4 service on multiple interfaces, it is multi-homed.

cheers,
Ole

>>            space specified in [RFC5735] and also not in the reserved IP
>>            address space specified in [RFC6333], then the IPv6 CE Router

---

From: "George, Wes" <[email-masked]>
Date: Tue, 15 Nov 2011 09:02:12 -0500

>> the CPE should not be in charge of checking for "public" IPv4 presence and based upon that tear up/bring down the DSLite tunnel.  If the ISP (we're not present in retail) decides on configuring the CPE with a public IPv4, then he should be aware of his actions and remove either the tunnel or the DHCPv6 option for the tunnel from the configuration.

[WEG] More importantly, how would a CPE determine what addresses are public and what are private? Assuming simply public != RFC1918 isn't enough, whether draft-weil passes or not. Either you now have to take that space into account as additional private space, or you run the very real risk of folks using "public" addresses (squat) inside of private environments, or both.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 15 Nov 2011 15:01:12 +0000

Ok. So the scenario is an ISP provisions an IPv4 for internal use, subscriber's Internet traffic will use dslite. That implies the CPE will have the logic to funnel the traffic for proper routing decision. Change to "should" implies a lot. I would recommend to mention an example in the draft why a CPE has an IPv4 address but still uses dslite.

---

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

As I see it, there are 2 main transition scenarios around DS-Lite:

1. The customer has a NAT444 service and is being transitioned to
DS-Lite, to remove one layer of NAT, and maybe as part of a process to
remove IPv4 from the access network. In this case, the NAT444 address
provided to the CE router may be RFC1918, from some new address space
that may or may not be allocated for CGN deployments, or some other
bogon address that the CGN operator decided to use. The direction of
transition is towards DS-Lite, and away from native IPv4.

2. The customer has a public IPv4 address on the CE router WAN, but the
access network is preparing to stop supporting IPv4 in the access
network, and is moving all IPv4 connectivity to DS-Lite. The direction
of transition is towards DS-Lite and away from native IPv4.

3. The customer has DS-Lite, doesn't like it, so the provider is
transitioning him to an IPv4 service with a public IPv4 address to the
CE router WAN. The direction of transition is towards native IPv4 and
away from DS-Lite.

I don't see much of a case for DS-Lite to be transitioned to NAT444 as a
variant on scenario 3. But note that in the case of random bogon
addresses in scenario 1, we really have no idea as to whether the WAN
IPv4 address is public or private.

And the CE router really has no clue as to why it sees both native IPv4
and DS-Lite. It just knows that both are there, and needs simple rules
for dealing with the situation.

Barbara

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Nov 2011 10:00:15 +1100

As a user, I want to be able to specifiy who is providing my AFTR
service.  My ISP's AFTR boxes may suck or my ISP may be using NAT64
and in either case I want to be able to use a third party AFTR
service.

As a user, I want to be able to disable the use of DS-Lite.

As a user, I want my CPE to use DS-Lite if my ISP enables it.  (default)

As for routing when there is both a WAN IPv4 address and DS-Lite
available.  Route local addresses natively (WAN and LAN) and non-local
addresses via DS-Lite.  If there is a entry in the NAT's state table
use it in preference to DS-Lite.

As a user, I want to be able to specify whether the AFTR option is
advertised internally or not.   (default off?)

In message <750BF7861EBBE048B3E648B4BB6E8F4F20B1252E@crexc50p>, "STARK, BARBARA

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 16 Nov 2011 09:42:40 +0100

Well, I assume the situation will/might depend on area and ISP, but as a residential CPE, decisions like this are usually not left to the end-user.  The ISPs chooses the scenario.  The user can just either see some info on some GUI or maybe configure a very limited number of parameters.
Please also note, and correct me if I'm wrong but I don't think this is bound to area or ISP, the avg residential end-user doesn't know (or need to know ?) what an IP address is, what an IPv6 address is, what the diff is between them, what dslite is ...
In the end, the avg residential end-user just wants to have a solid, reliable service from his ISP.

Carl Wuyts

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Andrews
Sent: woensdag 16 november 2011 0:00
To: STARK, BARBARA H
Cc: [email-masked]
Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion

As a user, I want to be able to specifiy who is providing my AFTR service.  My ISP's AFTR boxes may suck or my ISP may be using NAT64 and in either case I want to be able to use a third party AFTR service.

As for routing when there is both a WAN IPv4 address and DS-Lite available.  Route local addresses natively (WAN and LAN) and non-local addresses via DS-Lite.  If there is a entry in the NAT's state table use it in preference to DS-Lite.

In message <750BF7861EBBE048B3E648B4BB6E8F4F20B1252E@crexc50p>, "STARK, BARBARA  H" writes:
> 2. The customer has a public IPv4 address on the CE router WAN, but 
> the access network is preparing to stop supporting IPv4 in the access 
> I don't see much of a case for DS-Lite to be transitioned to NAT444 as 
> a variant on scenario 3. But note that in the case of random bogon 
> And the CE router really has no clue as to why it sees both native 
> IPv4 and DS-Lite. It just knows that both are there, and needs simple 
> rules for dealing with the situation.
> 
> Barbara

---

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

Carl,

Did you see this email from me today?  Ralph already has one solution pushed forward in the DHC WG to deal with the DHCPv6 server storm.

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

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: Wednesday, November 16, 2011 4:43 PM
To: Mark Andrews; STARK, BARBARA H
Cc: [email-masked]
Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion

Carl Wuyts

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 16 Nov 2011 13:51:23 +0100

Yes, I did. There have been quite a few mails exchanged on this over the last few weeks.  If this materializes into rfc, we'll cope with it.  My concerns on all of these are not related to this storm issue in fact, just don't want too much linking in place (like dhcpv6 and RA, public v4 and dslite tunnel, etc), it makes things too complex and some improvements on descriptions, to avoid confusion.

Thx

Carl Wuyts

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: woensdag 16 november 2011 13:45
To: Wuyts Carl; Mark Andrews; STARK, BARBARA H
Cc: [email-masked]
Subject: RE: [v6ops] RFC6204bis-02: DS-Lite transition discussion

Carl,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: Wednesday, November 16, 2011 4:43 PM
To: Mark Andrews; STARK, BARBARA H
Cc: [email-masked]
Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion

Carl Wuyts

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

---

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

-----Original Message-----
From: George, Wes [mailto:[email-masked]] 
Sent: Tuesday, November 15, 2011 10:02 PM
To: Wuyts Carl; Lee, Yiu; Hemant Singh (shemant)
Cc: [email-masked]
Subject: RE: [v6ops] RFC6204bis-02

>[WEG] More importantly, how would a CPE determine what addresses are
public and what are private? Assuming simply public != RFC1918 isn't
>enough, whether draft-weil passes or not. Either you now have to take
that space into account as additional private space, or you run the
>very real risk of folks using "public" addresses (squat) inside of
private environments, or both.

We have discussed such a question in the cpe router design team.  The
private address space included RFC5735 and the reserved range in RFC
6333.  Current range suffices for a DS-Lite right now because even if a
range is very small DS-Lite also uses port + IP enlarges the range.  Of
course, stuff happens and some day the range may deplete and then
draft-weil or a squat range will need to be considered.  Thus a CE
router vendor is expected to provide a knob or a firmware upgrade when
the range changes.   We are leaning towards changing the MUST in the
bullet to a SHOULD as well.

Thanks,

Hemant

---

From: François-Xavier Le Bail <[email-masked]>
Date: Thu, 17 Nov 2011 08:12:31 -0800 (PST)

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

> From: Hemant Singh (shemant) <[email-masked]>
> To: "George, Wes" <[email-masked]>; Wuyts Carl <[email-masked]>; "Lee, Yiu" <[email-masked]>

Hemant,

RFC 6333 reserve 192.0.0.0/29 which is included in

"192.0.0.0/24 - This block is reserved for IETF protocol assignments." 
documented in RFC 5735.

So I think only reference to RFC 5735 is needed. 
Thanks,
Francois-Xavier

---

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

-----Original Message-----
From: François-Xavier Le Bail [mailto:[email-masked]] 
Sent: Friday, November 18, 2011 12:13 AM
To: Hemant Singh (shemant); George, Wes; Wuyts Carl; Lee, Yiu
Cc: [email-masked]
Subject: Re: [v6ops] RFC6204bis-02

>So I think only reference to RFC 5735 is needed. 

Good catch.  Will remove the reference to the range from RFC 6333.

Thanks,

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 21 Nov 2011 21:42:26 +0900

On Tue, Nov 15, 2011 at 16:10, Wuyts Carl <[email-masked]>wrote:

> No, DHCPv6 runs on top of PPP in this case, hence it cannot start before
> it is up, but there’s no link to RAs, which was the first statement: “link
> RA to DHCPv6”, so no RA needed to start DHCPv6 on this link, hence
> preferably protocols should not be linked.
>
But they are linked: DHCPv6 has to start after PPP starts. So you do
trigger DHCPv6 when another protocol comes up, at least for PPP. So in
theory you could do so for RAs as well.

> you can avoid tying the two protocols together?****
>
> We have different configuration possibilities here, one being not to
> listen to RA and configure the DHCPv6 client independent from the flags in
> it, so not wait for the RA indeed.  We’re IPv6 ready logo certified, core
> protocols phase II, so don’t worry, we respect the rules towards DAD and
> everything, we just don’t want to tie up protocols, i.e. no fixed link
> between the RA and DHCPv6, no matter Ethernet, PPP or whatever****
>
My point was that even on Ethernet, you can't immediately start DHCPv6 PD
as soon as link comes up. First you have to wait for the link-local address
to complete DAD. So there is a trigger on plain Ethernet too.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 21 Nov 2011 21:47:41 +0900

On Tue, Nov 15, 2011 at 16:33, Wuyts Carl <[email-masked]>wrote:

> Anyway, if you want to go more the up-to-date way: what about dhcpv6
> client availability on mobile devices (smartphones etc)?

Android doesn't support DHCPv6. What were you suggesting to use it for? I
tried to look back in the thread but I wasn't able to interpret the quoted
text.

---

From: jouni korhonen <[email-masked]>
Date: Tue, 22 Nov 2011 10:33:37 +0200

> Anyway, if you want to go more the up-to-date way: what about dhcpv6 client availability on mobile devices (smartphones etc)?

On cellular access side rather poor i.e. I know no phone/smartphone that is in production or are going to be in production soonish. Few reasons for that: if the cellular side is according to 3GPP specs then SLAAC is the only way to configure the address. Later on prefix delegation will be added but still SLAAC for the "WAN" address. Also the deployed gateway side has currently very little support for DHCPv6 and if any then it is for RFC3736.

- Jouni

---

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

Ted was referring to some scenario to bridge in the LAN hosts, and let them execute the DHCPv6 client.
So I was pointing to Windows XP, not having DHCPv6 client functionality onboard.  Ted answered on this "so what about win95", meaning that I should look forward, not backward.  Although I think my statement , "still" looking to XP, is really a good one, as it still is massively around, I just gave him another set of devices, smartphones, typically not having dhcpv6 client functionality.
And as you confirm, indeed, Android doesn't support it.  Tx for confirmation :-)

Carl Wuyts

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: maandag 21 november 2011 13:48
To: Wuyts Carl
Cc: Ted Lemon; [email-masked]
Subject: Re: [v6ops] RFC6204bis-02

On Tue, Nov 15, 2011 at 16:33, Wuyts Carl <[email-masked]<mailto:[email-masked]>> wrote:
I agree, however, it's not me who has to agree.
Anyway, if you want to go more the up-to-date way: what about dhcpv6 client availability on mobile devices (smartphones etc)?

Android doesn't support DHCPv6. What were you suggesting to use it for? I tried to look back in the thread but I wasn't able to interpret the quoted text.

---

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

On Tue, Nov 22, 2011 at 18:11, Wuyts Carl <[email-masked]>wrote:

> So I was pointing to Windows XP, not having DHCPv6 client functionality
> onboard.
>

Windows XP doesn't have IPv6 enabled by default, so it doesn't matter.