Subject: [Softwires] DS-Lite mode enforcement to CPE routers

From: Daniel Roesen <[email-masked]>
Date: Tue, 1 Mar 2011 20:58:41 +0100

Hi,

lets assume following (DHCP on WAN side) scenario:

A) DHCP used on WAN side to obtain WAN address/LAN prefix
B) CPE routers deployed are generally dual stack enabled, by default
C) as a consequence, those CPE routers do emit both DHCPv4 and DHCPv6
requests on WAN side, no customer interaction/configuration required

In this scenario, CPE routers would come up dual-stacked on WAN and LAN
side just fine.

Now growing residential ISPs might be forced to break the
1-IPv4-per-active-customer model (v4 depletion!) and thus deploy some
kind of LSN.

If the chosen approach is DS-Lite, the ISP needs at some point in time
start to provision customers in a way to make sure they'll use DS-Lite
for IPv4 connectivity to conserve IPv4 addresses in a plannable manner.
"plannable manner" means specifically that the DS-Lite provisioned
customer cannot opt-out of using DS-Lite by turning off DS-Lite in the
CPE router and then again get a public IPv4 address via DHCPv4.

Ideally (that's the goal), wether CPE router has to use DS-Lite or just
go for DHCPv4 (dual stack mode) should be signalled by the ISP to the
CPE router device. Or more precise: there should be a way for an ISP to
signal a CPE router that is absolute has to use DS-Lite to obtain IPv4
connectivity as DHCPv4 will fail. The customer should not have to know
what "DS-Lite" is or - even worse - explicitly enable it in the CPE
router GUI in order to get IPv4 connectivity behind a "DS-Lite
connection".

As far as I read the current drafts, there is no standardised way to
do that.

draft-ietf-softwire-ds-lite-tunnel-option-08 says about client behavior:

   A client that supports the B4 functionality of DS-Lite (defined in
   [I-D.softwire-ds-lite]) and conforms to this specification MUST
   include OPTION_AFTR_NAME on its OPTION_ORO.

What does "supports" mean? Has the code, or also has DS-Lite
administratively "enabled"?

Let's assume "has the code". So a CPE router implementing DS-Lite
will ask for AFTR address in DHCPv6 request.

The draft outlines regarding DHCPv6 Server behaviour:

   RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and
   server negotiate configuration values using the Option Request Option
   (OPTION_ORO).  As a convenience to the reader, we mention here that a
   server will not reply with a AFTR-Name option if the client has not
   explicitly enumerated it on its Option Request Option.

I think that (will not reply [unless asked for]) is not really correct.
RFC 3315 17.2.2 says:

   The server includes options the server will return to the client in a
   subsequent Reply message. [...] If the client has included
   an Option Request option in the Solicit message, the server includes
   options in the Advertise message containing configuration parameters
   for all of the options identified in the Option Request option that
   the server has been configured to return to the client.  The server
   MAY return additional options to the client if it has been configured
   to do so. [...]

So in fact, "will not reply" is not the full truth.

One possible approach to DS-Lite enforcement could be:

- block DHCPv4 (don't reply)
- always deliver AFTR address in DHCPv6 replies
- ask CPE router vendors to take unsolicited AFTR address response as
  "DS-Lite required", to automatically enable DS-Lite operations on the
  CPE.

If above analysis is correct, I think the AFTR DHCP option draft would
need a correction about DHCP client behaviour, and if this "DS-Lite
enforcement" approach would be deemed suitable for standardisation,
include behaviour specification as well.

I think it would be wise to standardise an "enforcement" scheme to avoid
operators telling their CPE router vendors to implement "special hacks"
which are operator-specific.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Mar 2011 20:07:48 +0000

Hi Daniel,

draft-ietf-softwire-ds-lite-tunnel-option defines the behavior how the B4
obtains the AFTR information. It is not to define to use dhcp to signal
the B4 to use dual-stack mode or ds-lite mode.

For your question, if the ISP provisions the dhcp server not to respond
dhcpv4 request from the B4, the B4 would use dhcpv6 to obtain the AFTR
information. This should be sufficient.

Am I missing something? Comments?

Cheers,
Yiu

On 3/1/11 2:58 PM, "Daniel Roesen" <[email-masked]> wrote:

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

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 1 Mar 2011 21:49:15 +0100

Hi Yiu,

> the B4 to use dual-stack mode or ds-lite mode.

What would be the more appropriate place if not there?

Even if deemed out of scope, wouldn't a correction to the RFC3315 reference
("will not reply") be imperative? Or do I misread something?

> information. This should be sufficient.

So your suggestion would be to have the CPE implementing DS-Lite to
always ask for the AFTR address, but enable DS-Lite mode automatically
only and exactly if the DHCPv4 request fails?

I think there should be some guidance on recommended CPE router
behaviour in either the ds-lite spec or the ds-lite DHCP option spec.
Otherwise, I see DS-Lite coming in CPE routers as just an option which
needs to be manually turned on by the customer - or every CPE router
vendor developing their own heuristics. We'd like to avoid that.
How to enforce DS-Lite operations is something that should be
standardised so we can point vendors on the specification how to behave.

We could probably stick it into the v6ops cpe-router-bis draft, but that
would mean that this document needs guidance for every transition
mechanism with similar scenarios - wouldn't it be better to describe
desired CPE behaviour for a specific transition technologie in the spec
of that?

Best regards,
Daniel

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 1 Mar 2011 21:08:51 +0000

Hi Daniel,

See comments inline:

>> information. This should be sufficient.

[YL] I will let the authors to answer this question.

>desired CPE behaviour for a specific transition technologie in the spec

[YL] I agree with you this have to be specified. I can think of either the
cpe-router-bis draft or the draft-dslite-deployment should specify the
exact behavior. Do you agree that the draft-dslite-deployment is a good
place to define this behavior?

With the open-source code I use for test, I have to manually configure the
CPE to the dslite mode, but this is less than ideal. I remember I
previously discussed this with the cpe-router-bis's authors. I will have
to dig up the old mails to find out what conclusion we reached.

Regards,
Yiu

---

From: Alain Durand <[email-masked]>
Date: Tue, 1 Mar 2011 13:09:39 -0800

Daniel,

We have talked in the past within the working group about how should a CPE decide in which mode to boot:
IPv4-only, IPv6-only, full dual-stack, DS-Lite or 6rd...

We agreed to punt this until the specs were completed, so now would be the time to restart this effort.
The technique that was proposed a few years back is for the CPE to start both DHCPv4 and DHCPv6
at the same time and see if a 6rd option or DS-Lite option comes, and if it does, about the other one.

As chair of the wg, I would welcome a document explaining this in more details....

   - Alain.

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 1 Mar 2011 22:36:13 +0100

> place to define this behavior?

Not really. Operators need a normative specification to point CPE router
vendors at. draft-dslite-deployment aims to be "Informational" and
"discusses" things. It doesn't mandate specific behaviour. The strongest
guidance I read in the document is that B4 SHOULD implement the DHCP
option.

It's already hard to push vendors to implement things in moving drafts,
but it will be even harder to ask them to implement what they read into
informational documents. :-)

On a side note, it would be reallyreally good if we would get the DHCP
option draft to RFC as quick as possible in order to have vendors
actually implement the proper final IANA assigned DHCP option -
currently it's all custom handwaving, making interop testing hard at
best.

> CPE to the dslite mode, but this is less than ideal.

Indeed. Current implementation we test with has a GUI switch:

(*) native IPv4 (DHCPv4)
( ) DS-Lite

No "auto" heuristics, and DHCPv4 being default with no automatic DS-Lite
"fallback". In fact, any customer with a DS-Lite-only provisioned
connection would have to change that option in order to come online
proper if it would remain like that.

Next week we'll get the next DS-Lite pre-production test implementation
of another major CPE router vendor on the test bench - I'm eager to see
how DS-Lite "optionality" is done there. They are expecting us to tell
them how it's done "right" from an operational point of view - but
that shouldn't be ISP-specific, but well reviewed guidance from
some normative spec (sorry, I'm repeating myself I guess).

> I remember I previously discussed this with the cpe-router-bis's
> authors. I will have to dig up the old mails to find out what
> conclusion we reached.

Thanks!

Best regards,
Daniel

---

From: Ralph Droms <[email-masked]>
Date: Tue, 1 Mar 2011 16:47:50 -0500

This behavior should most likely be specified in the cpe-router-bis draft.  It may interact with other Initialization behaviors, as well.

- Ralph

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 1 Mar 2011 22:47:52 +0100

Hi,

On Tue, Mar 01, 2011 at 01:09:39PM -0800, Alain Durand wrote:
> We have talked in the past within the working group about how should
> a CPE decide in which mode to boot: IPv4-only, IPv6-only, full
> dual-stack, DS-Lite or 6rd...
>

Actually it's "too late" given that it probably takes many months to get
a new document done. Some operators are forced to move to deployment
very soon.

> The technique that was proposed a few years back is for the CPE to
> start both DHCPv4 and DHCPv6 at the same time and see if a 6rd option
> or DS-Lite option comes, and if it does, about the other one.

Could you rephrase the last part of this sentence ("about the other
one")?

> As chair of the wg, I would welcome a document explaining this in

I'm not sure a single document trying to define the complete heuristic
model would be a good approach, given that it would have to take "all"
somewhat popular techniques into consideration. What would be sensible
scoping where to stop?

As much as I'm interested in getting that stuff defined, I fear I
personally don't have the time do all the prose, but I'll certainly
try to provide input from operator perspective if anyone volunteers to
lay down the foundation. I'm also not into IETF processes so it'd be
better to have someone in the know take the lead on that.

Best regards,
Daniel

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 1 Mar 2011 22:56:38 +0100

On Tue, Mar 01, 2011 at 04:47:50PM -0500, Ralph Droms wrote:
> This behavior should most likely be specified in the cpe-router-bis
> draft.  It may interact with other Initialization behaviors, as well.

I agree that this might be the most sensible place.

So I should take the issue to v6ops?

Best regards,
Daniel

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 1 Mar 2011 23:22:44 +0100

> draft.  It may interact with other Initialization behaviors, as well.

I've just noticed that cpe-router-bis already takes a stab at it (I
blame it on my lack of sleep that I missed it before), in chapter 5.6.3.

What's probably missing there is the bigger picture with implications on
how provisioning models should look like (e.g. make sure that the
DHCPv4/v6 servers involved only return either DS-Lite AFTR in DHCPv6,
or 6RD BR in DHCPv4, but not both at the same time. Also it should
define behaviour in case the options are returned without being asked
for.

Sorry if I'm a bit "hectic" and didn't do my homework properly before
posting, "making noise" in the wrong places.

Best regards,
Daniel

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Wed, 02 Mar 2011 09:15:14 +0100

Hi,

That's what one of benefits of A+P architecture is.

See draft-ymbk-aplusp, section 3.3.4.  "Overall A+P Architecture"

Our idea is incremental deployment. Today ISP can put PRR in his network 
and start shipping out CPEs with A+P semantics deployed (if there would 
be any serious implementation and if we would not be delayed for a year 
with this draft by "they know who they are").

Idea is that you can allocate public IP with full port range to the 
customer and he would not notice the difference. With time you have a 
customer base able to share the IP and when you hit the point in your 
IPv4 stock that you decide you need to share IP addresses you just send 
out a new data-plan possibility (maybe even cheaper) and inform users 
that they can enable it with just a flick of the switch on service pages 
- you only need to change the behaviour of the encapsulation and 
allocate limited set of ports to a customer. This way you still give the 
user public IP address but with limited set of prots. You can go even 
further and offer CGN-like access, but then that wouldn't be worth more 
than 1EUR/month :)

It's there in architecture and it's unique. Current popular transition 
ideas tends to enforce violent mass deployment in a single short period 
of time, when you need to do switchover.

Cheers, Jan Zorz

---

From: Ralph Droms <[email-masked]>
Date: Wed, 2 Mar 2011 07:19:04 -0500

Daniel - can you take these thoughts to v6ops and add them to the discussion of CPE-router-bis?

- Ralph

---

From: Alain Durand <[email-masked]>
Date: Wed, 2 Mar 2011 07:44:56 -0800

> Could you rephrase the last part of this sentence ("about the other

Start DHCPv4 & DHCPv6
If both comes up with addresses, you're done. dual-stack mode.
If DHCPv4 still waiting and you get a DS-lite option from DHCPv6, abort DHCPv4. You are in DS-Lite more
If DHCPv6 still waiting and you get a 6rd option from DHCPv4, abort DHCPv6. You are in 6rd mode.

Alain.