Subject: [v6ops] draft-ietf-v6ops-6204bis WGLC

From: Fred Baker <[email-masked]>
Date: Fri, 9 Mar 2012 06:30:53 +0900

This is to initiate a two week working group last call of draft-ietf-v6ops-6204bis. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. The draft will be on the agenda at IETF 83, and I would like to send the authors home with a work plan to complete it if it is not to the WG's liking.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

---

From: Ole Trøan <[email-masked]>
Date: Fri, 9 Mar 2012 12:50:37 +0100

> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an importa…

I've done a review of the bis document against RFC6204. please find my comments below.

Major:
======

1. The DHCP "problem".
   UNH testing uncovered quite a few issues with the 3315/3633 protocol specifications with
   regards to support for both IA_NA and IA_PD. these issues are debated in DHC and there will be a DHC
   bar/DT meeting to see if those issues can be resolved and how. 6204bis depends on the outcome of this and
   shouldn't proceed before we know what requirements to make on DHCP.
   This is a problem we need to solve, and I don't think we can be silent on it.
   (e.g. bis has removed 6204, W-5. this also affects WPD-6.)
   Suggestion: Await resolution in DHC and adopt requirements accordingly.

2. PCP text is incomplete. As specified PCP support in the document is incomplete.
   If this has been added for DS-lite support draft-dupont-pcp-dslite-01
   should be referenced. Currently the requirement is not testable. E.g.
   it doesn't even specify which PCP server the client should use.
   In my opinion it also need to specify PCP/proxy LAN side behavior.
   (or reference a homenet document if one existed)
   Suggestion: Get thorough review in PCP and HOMENET. Incorporate LAN side requirements.

3. Section 4.4.1: transition mechanisms for IPv6. in introducing 6rd, 
   a CE might end up being multi-homed. that opens up
   a can of worms that the draft is silent on. either include the requirements from
   draft-townsley-troan-ipv6-ce-transitioning-02 incorporated or specify that native an 6rd are mutually
   exclusive.
   Suggestion: Incorporate requirements from above draft.

4. life-extension mechanisms for IPv4. firstly I don't think this mechanism belongs in this document, which 
   is all about delivering IPv6 service, while DS-lite is all about delivering IPv4 service.
   in addition to creating the same multi-homing issue (now for IPv4) above, it also has missing pieces.
   e.g. assigning full global addresses, something that is being worked on in softwire. fourthly (have I got
   that far) there are a number of proposals in softwires for complementary / competing mechanisms for
   IPv4 life extensions. NAT464, MAP-{T,E}, 4rd-U. there is also SD-NAT which achieves the same, but doesn't
   use IPv6 transport at all. I would prefer that none of these was in _this_ document, but that we had a separate
   document for "Life extensions for IPv4 CEs"

Minor:
======

1. Section 3.2.1: Why is this section removed?
   A dual-stack host is multihomed to IPv4 and IPv6 networks. The IPv4 and IPv6 topologies
   may not be congruent, and different addresses may have different reachability, e.g., ULAs.
   A host stack has to be able to quickly fail over and try a different source address and destination
   address pair if communication fails, as outlined in [HAPPY-EYEBALLS].
   Suggestion: Add back the missing paragraph.

2. W-3. Question: is there a need for "Router Discovery" to continue forever?
   Compared to todays behavior where it times out after 3 attempts?

3. WAA-4. Has added support for the DNS Search List option.
   The CPE acts as a demarcation point between two administrative domains.
   It will pass some information learnt from the WAN side DHCP client to its LAN
   side DHCP server. I think it is a particularly bad idea to let the ISP set the
   DNS search lists for hosts within my home.
   Why is this option added and what is the use case?
   Suggestion: Remove requirement for DNSSL

4. RFC6204 WAA-7 has been removed. Is that a good idea?
   I think this point is important to make it clear that RA and DHCP processing
   can be done independently of each other.
   Suggestion: Add requirement back.

5. New WAA-7. I think the added "unless configured to require a global IPv6
   address on the WAN interface.", dilutes the purpose of that requirement.
   The RFC6204 profile is meant to result in a router that can be plugged into any
   access network. Even though certain access networks will not operate the unnumbered
   addressing model, how are we going to ensure that no user moves this CPE to
   another access network, that requires it?
   How is this additional "unless configured" testable?
   This same comment applies to WPD-6.
   Suggestion: Remove addition text on WPD-6 and WAA-7.

6. WPD-1. Generally we have tried to avoid having multiple 2119 keywords in one
   requirement. Make PD-exclude a separate requirement.
   Suggestion: Split requirement in two.

7. WPD-4. I disagree with this requirement. It is also hard to test, and becomes
   meaningless, given that a CPE must do PD even if M=0, O=0.
   Suggestion: revert back to RFC6204:WPD-4

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 9 Mar 2012 10:46:51 -0600

Ole,

General comment.  Some folks would have liked to LastCall rfc6204bis during December 2011.  Rfc6204bis now seems to be in a mode such as the mode the ipv6 node-requirement document was in.  The ipv6 node-requirement document will always miss something that someone wants but the document is not held back after a certain set of requirements are in.  Most issues raised below have been beaten to death and we still have no resolution on the issues.  It's up to the WG to decide how long should rfc6204bis wait and punt to rfc6204ter?  See in line below.

I will reply on the PCP and draft-dupont in another email so that the comments do not get cluttered in this CE router discussion.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Trøan
Sent: Friday, March 09, 2012 6:51 AM
To: [email-masked] WG
Cc: [email-masked] Chairs; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>   Suggestion: Await resolution in DHC and adopt requirements accordingly.

Waited for three months now having contacted the DHC WG with the issues.  Actually it's more than three months because the issues were known to some DHC experts who are also on the cpe router design team.  There is still no resolution.   Why wait? A rfc6204ter can cover the DHC solutions when the solutions become available.  Alternatively, when rfc6204bis is in the IESG, if DHC has any resolution, one could incorporate the changes.

>   Suggestion: Incorporate requirements from above draft.

The document above will take time to gestate in the IETF.  Unless the document above is an RFC and some working implementations have shown the algorithms of the document working, rfc6204bis cannot do anything about this work.  I would continue rfc6204bis without this work.

>   document for "Life extensions for IPv4 CEs"

We are going down the rathole again trying to label DS-Lite as IPv4 tech but it's beaten to death the issue is debatable.  Life extensions is very IPv4 specific.  The kitchen sink of other new transition tech have to all reach RFC form before any CPE router document can consider them.  Move this work to rfc6204ter.

We can have a Webex meeting to discuss the minor issues raised and then publish the closure to v6ops for further comments.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 9 Mar 2012 11:57:48 -0600

Ole, authors of pcp-dslite, any SP testing PCP with DS-Lite, and v6ops,

Please see below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Trøan
Sent: Friday, March 09, 2012 6:51 AM
To: [email-masked] WG
Cc: [email-masked] Chairs; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>   Suggestion: Get thorough review in PCP and HOMENET. Incorporate LAN side requirements.

Provision manually or use a new DHCPv6 option.  SPs who are testing PCP can respond as well.  These minor issues should not block adding a PCP client to the rfc6204bis document.  Further draft-dupont-pcp-dslite-01 is not in RFC form nor in the IESG.  Additionally the pcp-dslite document needs a peer review.  What is the Appendix A in pcp-dslite talking about including mention of a "tag"?  Why is the tag needed when pcp-base already supports the necessary protocol?  Here is how.

The basic PCP header includes the source IP address of the PCP client issuing the PCP request.  Thus even though the IPv4 PCP request reaches the CGN in an IPv6 tunnel, the CGN decapsulates the tunneled packet and passes the packet to the IPv4 stack on the CGN.  The IPv4 stack passes the PCP Request to the PCP server.  Snipped from section 6.1 of pcp-base it this text.

[IPv4 is represented using an IPv4-mapped IPv6 address.]

Thus the PCP server is able to reply back to the PCP client in an IPv6 tunneled PCP response back.

I question why pcp-dslite document is needed if pcp-base already covers the technical details.

Hemant

---

From: Daniel Roesen <[email-masked]>
Date: Fri, 9 Mar 2012 22:41:38 +0100

Hi,

WAA-4: I've seen vendors appending DHCPv6-received DNS servers to the list
of already learned DNS servers and thus not actually using them unless
the formerly learned DNS servers become unresponsive. My operator-hat
expectation would be that the communicated list of DNS servers upon
RENEW is the only set of DNS servers to be used in the future.
Should we add further text making the (to an operator) obvious explicit
to close that hole?

WAA-5: I've seen vendors requesting SNTP servers but not using them.
Passes RFC6204 by-the-letters verification, but certainly not the
intention. Further text required to close such loopholes?

Best regards,
Daniel

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 9 Mar 2012 16:09:47 -0600

Daniel,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Daniel Roesen
Sent: Friday, March 09, 2012 4:42 PM
To: [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>intention. Further text required to close such loopholes?

Does the following change work for you?

Old
----

WAA-5:  The IPv6 CE router SHOULD support the DHCPv6 Simple Network
           Time Protocol (SNTP) option [RFC4075] and the Information
           Refresh Time option [RFC4242].

New
----

WAA-5:  The IPv6 CE router SHOULD support the Simple Network
           Time Protocol (SNTP) as specified in [RFC 2030].  If the CE
router
        implements SNTP, then the CE router requests the SNTP option
[RFC4075] 
         and the Information Refresh Time option [RFC4242] in DHCPv6
messages.

I will get back to you on the other issue you raised related to WAA-4.

Thanks much,

Best regards back,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 9 Mar 2012 16:26:27 -0600

Daniel,

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

>Should we add further text making the (to an operator) obvious explicit

I agree and also verified that RFC 3646 does not prohibit the new
behavior you asked of above.  After all, one use case is when the SP
signals a DHCPv6 Reconfigure from the DHCPv6 server to the client to ask
the client to Renew.  On receiving the Reconfigure message, the client
issues a RENEW.  After all, the motive of the SP with the Reconfigure
was to ask the client to obtain new information and a DNS server(s) list
qualifies as new information.  The client should purge any old
information.  Cced this email to Bernie (DHCPv6 guru) and Dan (DNS guru)
for any comments. 

If others agree, text in WAA-4 can be updated.

Best regards,

Hemant

---

From: Daniel Roesen <[email-masked]>
Date: Fri, 9 Mar 2012 23:38:54 +0100

Hi Hemant,

On Fri, Mar 09, 2012 at 04:09:47PM -0600, Hemant Singh (shemant) wrote:
>         Time Protocol (SNTP) as specified in [RFC 2030].  If the CE router
>         implements SNTP, then the CE router requests the SNTP option [RFC4075] 
>         and the Information Refresh Time option [RFC4242] in DHCPv6 messages.

Hm, I don't think that buys us anything. The implementation I had in
mind actually does implement (S)NTP, but keeps using the configured
set of NTP servers (pool.ntp.org servers by default). Your lingo still
would allow that. Also, the proposed text probably unintentionally
conditionalizes the IRT option request to wether the CE implements SNTP.
Where the SNTP and IRT topics are actually totally orthogonal and should
probably be splitted into two requirements.

What about:

WAA-5:  The IPv6 CE router SHOULD implement the Simple Network Time
        Protocol (SNTP) as specified in [RFC 2030].  If the CE router
        implements SNTP, it requests the SNTP option [RFC4075] and uses
        the received list of servers as primary time reference, unless
        explicitly configured otherwise.

WAA-$NEW: The IPv6 CE router SHOULD implement the Information Refresh Time
        option [RFC4242] and associated behaviour.

This WAA-4 lingo makes sure operators can switch customers over to using
a different set of servers via RENEW (unless the end user overrides
automatic time reference acquisition by explicitly configuring a set
of servers). Similar goes for the WAA-4 problem. CE UIs should either
use "auto" (DHCPv6 DNS/SNTP options) _OR_ local config overrides. And if
using "auto", a received set of DNS/SNTP servers are supposed to be the
only servers to be used from now on.

Best regards,
Daniel

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 9 Mar 2012 16:39:34 -0600

Perhaps I missed it, but I don't see any good text in RFC 3315 one can
point that says exactly what a client should do with "updated"
other-configuration options. The assumption would be to replace it
(remove the old, add the new). Though of course there are interesting
corner cases - what if the new Reply doesn't have the option (remove the
old?).

>From RFC 3315:

18.1.8. Receipt of Reply Messages

...

   Management of the specific configuration information is detailed in
   the definition of each option in section 22.

So I guess by extension responsibility for this falls on the option
specification documents. Yet, RFC 3646 is silent about this (as I
suspect are more of the documents).

-	Bernie
_____________________________________________
From: Hemant Singh (shemant) 
Sent: Friday, March 09, 2012 5:26 PM
To: Daniel Roesen; [email-masked]; [email-masked]
Cc: Dan Wing (dwing); Bernie Volz (volz)
Subject: RE: [v6ops] draft-ietf-v6ops-6204bis WGLC

Daniel,

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

Best regards,

Hemant

---

From: Daniel Roesen <[email-masked]>
Date: Fri, 9 Mar 2012 23:46:17 +0100

On Fri, Mar 09, 2012 at 04:26:27PM -0600, Hemant Singh (shemant) wrote:
> information.

Exactly that was what we tested, and observed behaviour was quite
"suprising" and unpleasant, but still legal to the letters.

I wonder wether have to make that more explicit in other areas as well.
Think of AFTR_FQDN for example.

I'd love to see some requirement text in RFC6204bis which explicitly
outlines that information obtained via RENEW MUST override any other
information earlier via DHCPv6. This avoids discussing that for all
options one by one (DNS servers, SNTP servers, AFTR FQDN, 6RD BR, ...).

Best regards,
Daniel

---

From: Daniel Roesen <[email-masked]>
Date: Sat, 10 Mar 2012 00:06:46 +0100

On Fri, Mar 09, 2012 at 04:39:34PM -0600, Bernie Volz (volz) wrote:
> (remove the old, add the new).

Indeed. Not everyone seems to share that assumption though. :)

> Though of course there are interesting corner cases - what if the new
> Reply doesn't have the option (remove the old?).

I would expect that, yes. There is no point in strict additive
behaviour.

Then again, "replace" behaviour raises the question what a multihomed
CE should do which receives conflicting information from multiple DHCPv6
servers. This might/will lead to "flapping" behaviour, especially with
short RENEW timers.

Best regards,
Daniel

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 9 Mar 2012 17:10:14 -0600

Another solution (or in addition to) may be to file ERRATA on the
particular RFC(s).

A general statement in RFC 3315 might also be an ERRATA to consider, but
I suspect it would be difficult to write and might lead to problems if
applied to options it wasn't intended to apply to. That's probably why
RFC 3315 is silent about it.

Add something the DHC WG should consider when writing new option drafts.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Daniel Roesen
Sent: Friday, March 09, 2012 5:46 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

On Fri, Mar 09, 2012 at 04:26:27PM -0600, Hemant Singh (shemant) wrote:
> signals a DHCPv6 Reconfigure from the DHCPv6 server to the client to 
> ask the client to Renew.  On receiving the Reconfigure message, the 
> client issues a RENEW.  After all, the motive of the SP with the 
> Reconfigure was to ask the client to obtain new information and a DNS 
> server(s) list qualifies as new information.  The client should purge 
> any old information.

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 9 Mar 2012 17:56:18 -0600

Daniel,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Daniel Roesen
Sent: Friday, March 09, 2012 5:39 PM
To: [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>        explicitly configured otherwise.

Works for me.

>        option [RFC4242] and associated behaviour.

Splitting to a new bullet makes perfect sense.  Slightly changed text
below.

WAA-$NEW: The IPv6 CE router SHOULD implement the Information Refresh
Time
        option and associated client behavior as specified in [RFC4242].

Thanks much.

Best Regards,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 9 Mar 2012 18:11:12 -0600

Bernie,

_____________________________________________
From: Bernie Volz (volz) 
Sent: Friday, March 09, 2012 5:40 PM
To: Hemant Singh (shemant); 'Daniel Roesen'; [email-masked]';
[email-masked]'
Cc: Dan Wing (dwing); Ralph Droms (rdroms)
Subject: RE: [v6ops] draft-ietf-v6ops-6204bis WGLC

>corner cases - what if the new Reply doesn't have the option (remove
the old?).

I would remove the old because the old would have been asked of in the
Renew and the server did not include the option in the reply.  It would
be good to initiate a discussion in the DHC WG and cc v6ops on this
topic.  I think we may have a critical mass of issues to embark on a
rfc3315bis.  It is also interesting that we have to go to other RFCs
related to DHCPv6 options to specific such specific behavior there.
Maybe there is a magic wand that specifies text in a rfc3315bis to apply
to options in the other RFCs. 

Thanks much for jumping in on this one right away!

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 9 Mar 2012 18:20:58 -0600

Daniel,

-----Original Message-----
From: Daniel Roesen [mailto:[email-masked]] 
Sent: Friday, March 09, 2012 6:07 PM
To: Bernie Volz (volz)
Cc: Hemant Singh (shemant); [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>short RENEW timers.

For what it's worth, each DHCPv6 reply is associated with a specific
DHCPv6 client-id and server-id.  Thus each client updates specific
information for options received.  I suppose each ipv6 address in the
multihomed situation has its own DNS to go to etc., so conflicting
information does not matter.  

Best regards,

Hemant

---

From: Daniel Roesen <[email-masked]>
Date: Sat, 10 Mar 2012 12:08:01 +0100

> information does not matter.  

DNS resolving is a system-wide matter, not a per-interface/IP matter.

If a system wants to talk to random.fqdn, it resolves that FQDN via
whatever DNS recursors available to it, and then looks up the egress
interface (and thus source IP) to be used for connecting to that remote
system. How could you know which interface-specific recursor you'll use
before knowing which across which interface you're going to you to reach
the remote system? It's a catch 22.

Real world example: CE gets Internet uplink via PPPoE on one VLAN, and
IPTV uplink via DHCP via another VLAN. From both connections, a
conflicting set of DNS recursors are being obtained. Which set is the
one to use to forward proxied requests from LAN clients to? LAN contains
"Internet" clients as well as IPTV STBs - indistinguishable by the CE.

Best regards,
Daniel

---

From: Daniel Roesen <[email-masked]>
Date: Sat, 10 Mar 2012 12:10:43 +0100

>         option and associated client behavior as specified in [RFC4242].

That's even better indeed. Thanks!

Best regards,
Daniel

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 10 Mar 2012 09:10:24 -0600

Daniel,

Agree with you.  Thanks for the details below.  Also, as an FYI, the
both rfc6204 and rfc6204bis do not support multihoming for a feature.
Multihoming is future work going on in homenet.

One work going on in the DNS server selection area is this document.

http://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-01

Best regards,

Hemant

-----Original Message-----
From: Daniel Roesen [mailto:[email-masked]] 
Sent: Saturday, March 10, 2012 6:08 AM
To: Hemant Singh (shemant)
Cc: Bernie Volz (volz); [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

Best regards,

Daniel

--

---

From: Daniel Roesen <[email-masked]>
Date: Sat, 10 Mar 2012 17:40:12 +0100

> Multihoming is future work going on in homenet.

Sure, but vendors out there already support some kind of multihoming and
are certainly reluctant to implement behaviour incompatible with that.
:-)

It's about what we can reasonably ask for from those implementors.

Perhaps we shall ask to replace the set of servers received from the
same source. Which leads to the desired behaviour in the non-multihomed
scenario assumed in RFC6204(bis) and doesn't preclude vendor's solution
for multihomed scenarios.

> http://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-01

Thanks for the reference. Complex stuff which is probably impossible to
get right automagically (as noted in the draft as well).

Best regards,
Daniel

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 11 Mar 2012 10:01:38 -0500

Daniel and Bernie,

Please see a stab at the requirement Daniel asked for. 

-----Original Message-----
From: Daniel Roesen [mailto:[email-masked]] 
Sent: Friday, March 09, 2012 5:46 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>options one by one (DNS servers, SNTP servers, AFTR FQDN, 6RD BR, ...).

WAA-x Information in DHCPv6 options in a DHCPv6 REPLY in response to a
DHCPv6 RENEW message 

      MUST override existing information learnt via DHCPv6.  Further, if
the DHCPv6 RENEW message

      includes an option in the DHCPv6 ORO option but the server does
not return the option in the REPLY, 

      the CE router purges existing information related to the option.

Note the history of rfc6204/rfc6204bis has been that the document does
tighten text if the text in the existing protocol RFC is not as tight.
The reason is because the IPv6 CE router document is a device-specific
specification that can include tighter text.  One example is the W-5
bullet in rfc6204/rfc6204bis related to the MUST use a persistent DHCPv6
DUID.  RFC 3315 has a SHOULD requirement on the DUID persistence.  Thus
I think the rfc6240bis document can move forward with a new bullet above
while the DHCPv6 ERRATA takes its due course of action on existing
DHCPv6 documents.  Of course, the new text above is open to review by
the DHC WG.

Best regards,

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Mar 2012 10:14:02 +1300

Hi,

> 1.  Introduction
...
>    The document also covers IP transition technologies.  Two transition
>    technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in
>    the document.  At the time of writing this document these were the
>    only two transition technologies available in RFC form to be included
>    in this document.

The last sentence is untrue. There are many older transition technologies
in RFC form. Rather than trying to find an accurate formulation, I
suggest just dropping the sentence.

Along the same grounds, there is no mention in the document of protocol 41.
I realise that the draft is about IPv6, but should there be a note that
when the CPE is supporting IPv6 traffic, then there is no requirement for
it to allow protocol 41 in IPv4 traffic? (A stronger statement would be
that protocol 41 MUST be blocked by default, but that seems out of scope
for an IPv6 CPE document.)

    Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 11 Mar 2012 16:49:57 -0500

Brian,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian E Carpenter
Sent: Sunday, March 11, 2012 5:14 PM
To: Fred Baker (fred)
Cc: [email-masked]; [email-masked]; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>suggest just dropping the sentence.

The intent was to count only DS-Lite and 6rd since all other past
transition tech before these two were generally phased out.  However,
your point is taken and the sentence can be dropped.  There can be some
disagreement as to which prior transition tech is phased out or not.

>for an IPv6 CPE document.)

I think the document can be silent on protocol 41 since the document is
already supportive of 6rd.  Deciding any defaults for protocol 41 can be
a protracted discussion as well.

Thanks for the review.

Regards,

Hemant

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 12 Mar 2012 08:38:24 +0100

Well, I agree/confirm that it's a system wide decision, not per IP interface or whatever, but I don't really see an issue with it.  Maybe just a view on how it works on our CPEs, not sure how it is on others of course. 

Our DNS proxy can get its DNS Servers through static or dynamic configuration (PPP, DHCPv4/v6 ,...), so it can basically come from any "home" over any "IP interface".  On top, some configuration can be done to match certain criteria to prefer a certain DNS server to be selected for a specific query from the LAN segments.  When this is done, the packet is being handed over to the router, and this one will make the routing decision.  So indeed it is possible that DNS requests are being sent over another/"wrong" interface (than expected), but I'd say this is just configuration.  I mean, I can put some blackhole/null route in and make it go wrong too....  just FYI.  We work in a system with managed CPEs, so less vulnarable to thses kind of things I guess, but I don't agree that the CPE "doesn't know", it's a matter of proper configuration.   Situation might be different for retail I guess, as less control present, but still, it must be possible to put some configuration on it somehow, as it must be told what setup to serve anyway.

I also think this is not different from the past.  In a v4-only world, you can hit the same issue today, without RFc6204 presence, no ?

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Roesen
Sent: zaterdag 10 maart 2012 12:08
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

If a system wants to talk to random.fqdn, it resolves that FQDN via whatever DNS recursors available to it, and then looks up the egress interface (and thus source IP) to be used for connecting to that remote system. How could you know which interface-specific recursor you'll use before knowing which across which interface you're going to you to reach the remote system? It's a catch 22.

Real world example: CE gets Internet uplink via PPPoE on one VLAN, and IPTV uplink via DHCP via another VLAN. From both connections, a conflicting set of DNS recursors are being obtained. Which set is the one to use to forward proxied requests from LAN clients to? LAN contains "Internet" clients as well as IPTV STBs - indistinguishable by the CE.

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0 _______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Francis Dupont <[email-masked]>
Date: Mon, 12 Mar 2012 21:13:09 +0100

>     2. PCP text is incomplete. As specified PCP support in the document

=> I have a concern about the PCP text too (W-6 and/or change 12): I
believed we agreed to ask only for the functionality, not to specify
one of the protocols which provides it (even it is the only designed
by the IETF... did you say NIH? :-)

>     should be referenced.

=> I agree: if you have both PCP and DS-lite in the same document you have
to cite both the base spec and the environment application I-Ds.

>     Currently the requirement is not testable. E.g.

=> hum, perhaps we should add the PCP server discovery document
(when it will be available) too?

>     (or reference a homenet document if one existed)

=> it looks like a good idea but unconstrainted PCP/proxy raises a
security issue so IMHO we should keep this out of the scope of the
document. And also on the LAN side you have other protocols which
are already heavily used.

>     Suggestion: Get thorough review in PCP and HOMENET. Incorporate LAN

=> this is a more generic issue. I think the other transition mechanims
are the same, so the idea to jump to 6204ter is not bad...

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 12 Mar 2012 21:40:20 +0100

>  Ole, authors of pcp-dslite, any SP testing PCP with DS-Lite, and v6ops,

=> seems I belong to this list (:-)

>  Please see below.
>  
>  Further draft-dupont-pcp-dslite-01 is not in RFC form nor in the IESG.

=> I don't parse the 'in RFC form': do you have some concerns about
the pcp-dslite document (other than below)?

>  Additionally the pcp-dslite document needs a peer review.

=> of course it does. Are you candidate to review it (or co-author it)?
BTW I can explain the pcp-dslite document history: there are two
possible different modes so I asked one and only one would be
chosen. The answer was "help yourself" so I polled other PCP implementors
to get their opinion and co-authoring, became the editor of the document
which in fact is mainly about the mode choice. Since the last version
the WG moved all the DS-Lite related details from the base spec to
the pcp-dslite document (so a new version will be needed, for instance
for some security considerations which was removed).

> What is the Appendix A in pcp-dslite talking about including mention
> of a "tag"?  Why is the tag needed when pcp-base already supports
> the necessary protocol?  Here is how.

=> it is an appendix (so not normative) which tries to explain how
to implement the "other" mode on the server side. BTW I used the verb
"tag" because it is less overloaded than "label" and stronger than "link".

>  The basic PCP header includes the source IP address of the PCP client
>  issuing the PCP request.  Thus even though the IPv4 PCP request reaches
>  the CGN in an IPv6 tunnel, the CGN decapsulates the tunneled packet and
>  passes the packet to the IPv4 stack on the CGN.  The IPv4 stack passes
>  the PCP Request to the PCP server.  Snipped from section 6.1 of pcp-base
>  it this text.
>  

=> no, it is not able if it doesn't get the IPv6 address to select the
right tunnel, and this IPv6 is thrown away when the request tunneled is
decapsulated.
To summary you didn't understand the appendix A...

>  I question why pcp-dslite document is needed if pcp-base already covers

=> it is needed because there is an alternative to the encapsulation mode
(so two modes, i.e., one too many) which has some technical advantages
(mainly simpler to implement at the server side).

Note if you consider DS-Lite as being a particular case it should always
be a good idea to push it to a dedicated document as the base spec has
far too many things in it.

Regards

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 16 Mar 2012 08:48:23 -0500

Folks,

Here is the delta between -07 that was sent out for LastCall and -08 which has edits from review.  Three minor items from Ole need closure during this week.   PCP needs closure between Med and Francis.   Changes from DanielR, RayH, and Ole have been incorporated. 

Thanks,

Hemant

	< <http://www.ietf.org/tools/rfcdiff/rfcdiff.pyht?url2=draft-ietf-v6ops-6204bis-07.txt>  draft-ietf-v6ops-6204bis-07.txt <http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-07.txt>  

	 draft-ietf-v6ops-6204bis-08.txt <http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-08.txt>  > <http://www.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-v6ops-6204bis-08.txt> 

	Network Working Group                                           H. Singh

Network Working Group                                           H. Singh

	Internet-Draft                                                 W. Beebee

Internet-Draft                                                 W. Beebee

	Obsoletes: 6204 (if approved)                        Cisco Systems, Inc.

Obsoletes: 6204 (if approved)                        Cisco Systems, Inc.

	Intended status: Informational                                 C. Donley

Intended status: Informational                                 C. Donley

	Expires: September 9, 2012                                     CableLabs

Expires: September 17, 2012                                    CableLabs

	                                                                B. Stark

                                                                B. Stark

	                                                                    AT&T

                                                                    AT&T

	                                                           O. Troan, Ed.

                                                           O. Troan, Ed.

	                                                     Cisco Systems, Inc.

                                                     Cisco Systems, Inc.

	                                                           March 8, 2012

                                                          March 16, 2012

	           Basic Requirements for IPv6 Customer Edge Routers

           Basic Requirements for IPv6 Customer Edge Routers

	                      draft-ietf-v6ops-6204bis-07

                      draft-ietf-v6ops-6204bis-08

	Abstract

Abstract

	   This document specifies requirements for an IPv6 Customer Edge (CE)

   This document specifies requirements for an IPv6 Customer Edge (CE)

	   router.  Specifically, the current version of this document focuses

   router.  Specifically, the current version of this document focuses

	   on the basic provisioning of an IPv6 CE router and the provisioning

   on the basic provisioning of an IPv6 CE router and the provisioning

	   of IPv6 hosts attached to it.  The document also covers IP transition

   of IPv6 hosts attached to it.  The document also covers IP transition

	   technologies.  Two transition technologies in RFC 5969's 6rd and RFC

   technologies.  Two transition technologies in RFC 5969's 6rd and RFC

	   6333's DS-Lite. are covered in the document.  The document obsoletes

   6333's DS-Lite. are covered in the document.  The document obsoletes

	   RFC 6204, if approved.

   RFC 6204, if approved.

skipping to change at page 1, line 

42

skipping to change at page 1, line 

42

	   Internet-Drafts are working documents of the Internet Engineering

   Internet-Drafts are working documents of the Internet Engineering

	   Task Force (IETF).  Note that other groups may also distribute

   Task Force (IETF).  Note that other groups may also distribute

	   working documents as Internet-Drafts.  The list of current Internet-

   working documents as Internet-Drafts.  The list of current Internet-

	   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Drafts is at http://datatracker.ietf.org/drafts/current/.

	   Internet-Drafts are draft documents valid for a maximum of six months

   Internet-Drafts are draft documents valid for a maximum of six months

	   and may be updated, replaced, or obsoleted by other documents at any

   and may be updated, replaced, or obsoleted by other documents at any

	   time.  It is inappropriate to use Internet-Drafts as reference

   time.  It is inappropriate to use Internet-Drafts as reference

	   material or to cite them other than as "work in progress."

   material or to cite them other than as "work in progress."

				
	   This Internet-Draft will expire on September 9, 2012.

   This Internet-Draft will expire on September 17, 2012.

	Copyright Notice

Copyright Notice

	   Copyright (c) 2012 IETF Trust and the persons identified as the

   Copyright (c) 2012 IETF Trust and the persons identified as the

	   document authors.  All rights reserved.

   document authors.  All rights reserved.

	   This document is subject to BCP 78 and the IETF Trust's Legal

   This document is subject to BCP 78 and the IETF Trust's Legal

	   Provisions Relating to IETF Documents

   Provisions Relating to IETF Documents

	   (http://trustee.ietf.org/license-info) in effect on the date of

   (http://trustee.ietf.org/license-info) in effect on the date of

	   publication of this document.  Please review these documents

   publication of this document.  Please review these documents

skipping to change at page 3, line 

28

skipping to change at page 3, line 

28

	   of its LAN interfaces, and fetches other configuration information

   of its LAN interfaces, and fetches other configuration information

	   from the service provider network.  Automatic provisioning of more

   from the service provider network.  Automatic provisioning of more

	   complex topology than a single router with multiple LAN interfaces is

   complex topology than a single router with multiple LAN interfaces is

	   out of scope for this document.

   out of scope for this document.

	   See [RFC4779] for a discussion of options available for deploying

   See [RFC4779] for a discussion of options available for deploying

	   IPv6 in service provider access networks.

   IPv6 in service provider access networks.

 

   the document.

	   in this document.

	1.1.  Requirements Language

1.1.  Requirements Language

	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

	   document are to be interpreted as described in RFC 2119 [RFC2119].

   document are to be interpreted as described in RFC 2119 [RFC2119].

	2.  Terminology

2.  Terminology

	   End-User Network          one or more links attached to the IPv6 CE

   End-User Network          one or more links attached to the IPv6 CE

skipping to change at page 9, line 

8

skipping to change at page 9, line 

8

	           router MUST support IPv6 over PPP [RFC5072].

           router MUST support IPv6 over PPP [RFC5072].

	   WLL-3:  If the WAN interface supports PPP encapsulation, in a dual-

   WLL-3:  If the WAN interface supports PPP encapsulation, in a dual-

	           stack environment with IPCP and IPV6CP running over one PPP

           stack environment with IPCP and IPV6CP running over one PPP

	           logical channel, the Network Control Protocols (NCP's) MUST

           logical channel, the Network Control Protocols (NCP's) MUST

	           be treated as independent of each other and start and

           be treated as independent of each other and start and

	           terminate independently.

           terminate independently.

	   Address assignment requirements:

   Address assignment requirements:

				
	   WAA-1:  The IPv6 CE router MUST support Stateless Address

   WAA-1:   The IPv6 CE router MUST support Stateless Address

	           Autoconfiguration (SLAAC) [RFC4862].

            Autoconfiguration (SLAAC) [RFC4862].

				
	   WAA-2:  The IPv6 CE router MUST follow the recommendations in Section

   WAA-2:   The IPv6 CE router MUST follow the recommendations in

	           4 of [RFC5942], and in particular the handling of the L flag

            Section 4 of [RFC5942], and in particular the handling of

	           in the Router Advertisement Prefix Information option.

            the L flag in the Router Advertisement Prefix Information

		            option.

				
	   WAA-3:  The IPv6 CE router MUST support DHCPv6 [RFC3315] client

   WAA-3:   The IPv6 CE router MUST support DHCPv6 [RFC3315] client

	           behavior.

            behavior.

				
	   WAA-4:  The IPv6 CE router MUST be able to support the following

   WAA-4:   The IPv6 CE router MUST be able to support the following

	           DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and

            DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and

	           DNS_SERVERS [RFC3646].  The IPv6 CE router SHOULD be able to

            DNS_SERVERS [RFC3646].  The IPv6 CE router SHOULD be able to

	           support the DNS Search List DNSSL option as specified in

            support the DNS Search List DNSSL option as specified in

	           [RFC3646].

            [RFC3646].

				

            Protocol (SNTP) as specified in [RFC2030].  If the CE router

            implements SNTP, it requests the SNTP option [RFC4075] and

		            uses the received list of servers as primary time reference,

		            unless explicitly configured otherwise.

				
	   WAA-6:  If the IPv6 CE router receives a Router Advertisement message

   WAA-6:   The IPv6 CE router SHOULD implement the Information Refresh

	           (described in [RFC4861]) with the M flag set to 1, the IPv6

            Time option and associated client behavior as specified in

	           CE router MUST do DHCPv6 address assignment (request an IA_NA

            [RFC4242].

	           option).

				
	   WAA-7:  If the IPv6 CE router does not acquire global IPv6

   WAA-7:   If the IPv6 CE router receives a Router Advertisement

	           address(es) from either SLAAC or DHCPv6, then it MUST create

            message (described in [RFC4861]) with the M flag set to 1,

	           global IPv6 address(es) from its delegated prefix(es) and

            the IPv6 CE router MUST do DHCPv6 address assignment

	           configure those on one of its internal virtual network

            (request an IA_NA option).

	           interfaces, unless configured to require a global IPv6

	           address on the WAN interface.

				
	   WAA-8:  The CE Router MUST support the DHCPv6 SOL_MAX_RT option

   WAA-8:   If the IPv6 CE router does not acquire global IPv6

	           [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6

            address(es) from either SLAAC or DHCPv6, then it MUST create

	           Advertise or Reply message and set its internal SOL_MAX_RT

            global IPv6 address(es) from its delegated prefix(es) and

	           parameter to the value contained in the SOL_MAX_RT option.

            configure those on one of its internal virtual network

		            interfaces, unless configured to require a global IPv6

		            address on the WAN interface.

				
	   WAA-9:  As a router, the IPv6 CE router MUST follow the weak host

   WAA-9:   The CE Router MUST support the DHCPv6 SOL_MAX_RT option

	           (Weak ES) model [RFC1122].  When originating packets from an

            [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6

	           interface, it will use a source address from another one of

            Advertise or Reply message and set its internal SOL_MAX_RT

	           its interfaces if the outgoing interface does not have an

            parameter to the value contained in the SOL_MAX_RT option.

	           address of suitable scope.

		   WAA-10:  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.

	   Prefix delegation requirements:

   Prefix delegation requirements:

	   WPD-1:  The IPv6 CE router MUST support DHCPv6 prefix delegation

   WPD-1:  The IPv6 CE router MUST support DHCPv6 prefix delegation

	           requesting router behavior as specified in [RFC3633] (IA_PD

           requesting router behavior as specified in [RFC3633] (IA_PD

	           option).  The IPv6 CE Router SHOULD support the

           option).

		   WPD-2:  The IPv6 CE Router SHOULD support the

	           [I-D.ietf-dhc-pd-exclude] PD-Exclude option.

           [I-D.ietf-dhc-pd-exclude] PD-Exclude option.

				
	   WPD-2:  The IPv6 CE router MAY indicate as a hint to the delegating

   WPD-3:  The IPv6 CE router MAY indicate as a hint to the delegating

	           router the size of the prefix it requires.  If so, it MUST

           router the size of the prefix it requires.  If so, it MUST

	           ask for a prefix large enough to assign one /64 for each of

           ask for a prefix large enough to assign one /64 for each of

	           its interfaces, rounded up to the nearest nibble, and SHOULD

           its interfaces, rounded up to the nearest nibble, and SHOULD

	           be configurable to ask for more.

           be configurable to ask for more.

				
	   WPD-3:  The IPv6 CE router MUST be prepared to accept a delegated

   WPD-4:  The IPv6 CE router MUST be prepared to accept a delegated

	           prefix size different from what is given in the hint.  If the

           prefix size different from what is given in the hint.  If the

	           delegated prefix is too small to address all of its

           delegated prefix is too small to address all of its

	           interfaces, the IPv6 CE router SHOULD log a system management

           interfaces, the IPv6 CE router SHOULD log a system management

	           error.

           error.  [RFC6177] covers the recommendations for service

		           providers for prefix allocation sizes.

				
	   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix

   WPD-5:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix

	           delegation when either the M or O flags are set to 1 in a

           delegation when either the M or O flags are set to 1 in a

	           received Router Advertisement message.

           received Router Advertisement message.

				
	   WPD-5:  If the delegated prefix(es) are aggregate route(s) of

   WPD-6:  If the delegated prefix(es) are aggregate route(s) of

	           multiple, more-specific routes, the IPv6 CE router MUST

           multiple, more-specific routes, the IPv6 CE router MUST

	           discard packets that match the aggregate route(s), but not

           discard packets that match the aggregate route(s), but not

	           any of the more-specific routes.  In other words, the next

           any of the more-specific routes.  In other words, the next

	           hop for the aggregate route(s) should be the null

           hop for the aggregate route(s) should be the null

	           destination.  This is necessary to prevent forwarding loops

           destination.  This is necessary to prevent forwarding loops

	           when some addresses covered by the aggregate are not

           when some addresses covered by the aggregate are not

	           reachable [RFC4632].

           reachable [RFC4632].

	           (a)  The IPv6 CE router SHOULD send an ICMPv6 Destination

           (a)  The IPv6 CE router SHOULD send an ICMPv6 Destination

	                Unreachable message in accordance with Section 3.1 of

                Unreachable message in accordance with Section 3.1 of

	                [RFC4443] back to the source of the packet, if the

                [RFC4443] back to the source of the packet, if the

	                packet is to be dropped due to this rule.

                packet is to be dropped due to this rule.

				
	   WPD-6:  If the IPv6 CE router requests both an IA_NA and an IA_PD

   WPD-7:  If the IPv6 CE router requests both an IA_NA and an IA_PD

	           option in DHCPv6, it MUST accept an IA_PD option in DHCPv6

           option in DHCPv6, it MUST accept an IA_PD option in DHCPv6

	           Advertise/Reply messages, even if the message does not

           Advertise/Reply messages, even if the message does not

	           contain any addresses, unless configured to only obtain its

           contain any addresses, unless configured to only obtain its

	           WAN IPv6 address via DHCPv6.

           WAN IPv6 address via DHCPv6.

				
	   WPD-7:  By default, an IPv6 CE router MUST NOT initiate any dynamic

   WPD-8:  By default, an IPv6 CE router MUST NOT initiate any dynamic

	           routing protocol on its WAN interface.

           routing protocol on its WAN interface.

	4.3.  LAN-Side Configuration

4.3.  LAN-Side Configuration

	   The IPv6 CE router distributes configuration information obtained

   The IPv6 CE router distributes configuration information obtained

	   during WAN interface provisioning to IPv6 hosts and assists IPv6

   during WAN interface provisioning to IPv6 hosts and assists IPv6

	   hosts in obtaining IPv6 addresses.  It also supports connectivity of

   hosts in obtaining IPv6 addresses.  It also supports connectivity of

	   these devices in the absence of any working WAN interface.

   these devices in the absence of any working WAN interface.

	   An IPv6 CE router is expected to support an IPv6 end-user network and

   An IPv6 CE router is expected to support an IPv6 end-user network and

skipping to change at page 16, line 

28

skipping to change at page 16, line 

29

	              draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in

              draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in

	              progress), November 2011.

              progress), November 2011.

	   [I-D.ietf-dhc-pd-exclude]

   [I-D.ietf-dhc-pd-exclude]

	              Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,

              Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,

	              "Prefix Exclude Option for DHCPv6-based Prefix

              "Prefix Exclude Option for DHCPv6-based Prefix

	              Delegation", draft-ietf-dhc-pd-exclude-04 (work in

              Delegation", draft-ietf-dhc-pd-exclude-04 (work in

	              progress), December 2011.

              progress), December 2011.

	   [I-D.ietf-pcp-base]

   [I-D.ietf-pcp-base]

	              Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R.

              Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.

	              Penno, "Port Control Protocol (PCP)",

              Selkirk, "Port Control Protocol (PCP)",

	              draft-ietf-pcp-base-23 (work in progress), February 2012.

              draft-ietf-pcp-base-24 (work in progress), March 2012.

	   [RFC1122]  Braden, R., "Requirements for Internet Hosts -

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -

	              Communication Layers", STD 3, RFC 1122, October 1989.

              Communication Layers", STD 3, RFC 1122, October 1989.

				
		
   [RFC2030]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4

		              for IPv4, IPv6 and OSI", RFC 2030, October 1996.

	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

	              Requirement Levels", BCP 14, RFC 2119, March 1997.

              Requirement Levels", BCP 14, RFC 2119, March 1997.

	   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",

	              RFC 2131, March 1997.

              RFC 2131, March 1997.

	   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet

	              Networks", RFC 2464, December 1998.

              Networks", RFC 2464, December 1998.

	   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:

skipping to change at page 18, line 

25

skipping to change at page 18, line 

30

	   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4

	              Infrastructures (6rd) -- Protocol Specification",

              Infrastructures (6rd) -- Protocol Specification",

	              RFC 5969, August 2010.

              RFC 5969, August 2010.

	   [RFC6092]  Woodyatt, J., "Recommended Simple Security Capabilities in

   [RFC6092]  Woodyatt, J., "Recommended Simple Security Capabilities in

	              Customer Premises Equipment (CPE) for Providing

              Customer Premises Equipment (CPE) for Providing

	              Residential IPv6 Internet Service", RFC 6092,

              Residential IPv6 Internet Service", RFC 6092,

	              January 2011.

              January 2011.

				
		
   [RFC6177]  Narten, T., Huston, G., and L. Roberts, "IPv6 Address

		              Assignment to End Sites", BCP 157, RFC 6177, March 2011.

	   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-

	              Stack Lite Broadband Deployments Following IPv4

              Stack Lite Broadband Deployments Following IPv4

	              Exhaustion", RFC 6333, August 2011.

              Exhaustion", RFC 6333, August 2011.

	   [RFC6334]  Hankins, D. and T. Mrugalski, "Dynamic Host Configuration

   [RFC6334]  Hankins, D. and T. Mrugalski, "Dynamic Host Configuration

	              Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",

              Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",

	              RFC 6334, August 2011.

              RFC 6334, August 2011.

	   [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node

   [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node

	              Requirements", RFC 6434, December 2011.

              Requirements", RFC 6434, December 2011.

 End of changes. 25 change 

blocks. 

52 lines changed or deleted

66 lines changed or added

This html diff was produced by rfcdiff 1.39p1. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ <http://www.tools.ietf.org/tools/rfcdiff/>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 18 Mar 2012 12:01:40 -0500

Ole and Chris,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Trøan
Sent: Friday, March 09, 2012 6:51 AM
To: [email-masked] WG
Cc: [email-masked] Chairs; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>   Suggestion: revert back to RFC6204:WPD-4.

Note RFC 4861 says

[If neither M nor O flags are set, this indicates that no information is available via DHCPv6.]

Since the PD is acquired using DHCPv6, why should the CE WAN initiate DHCPv6 if no DHCPv6 services are available?  So why not stick with Chris' proposal of the changed WPD-4 in rfc6204bis?

I do have a question for Chris.  Why is Ralph's MAX_SOLO_RT DHCPv6 draft not sufficient to mitigate the pounding of the DHCPv6 server by a CE router asking for PD when the SP hasn't enabled PD services on the DHCPv6 server?  

Hemant

---

From: Fred Baker <[email-masked]>
Date: Sun, 18 Mar 2012 16:38:47 -0700

THanks. I think there is room for discussion at IETF 83, and the opportunity for anyone who hasn't made his case to make it. I'd like to believe that we can send it to Ron after the meeting.

On Mar 16, 2012, at 6:48 AM, Hemant Singh (shemant) wrote:

> < draft-ietf-v6ops-6204bis-07.txt 
>  draft-ietf-v6ops-6204bis-08.txt >
>  
>            Time Protocol (SNTP) option [RFC4075] and theInformation
>            Advertise or Reply message and set its internalSOL_MAX_RT
>               draft-ietf-pcp-base-23 (work in progress), February2012.
> This html diff was produced by rfcdiff 1.39p1. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
>  
>

---

From: Ole Trøan <[email-masked]>
Date: Sun, 18 Mar 2012 21:01:15 -0700

Hemant,

> [If neither M nor O flags are set, this indicates that no information is available via DHCPv6.]

fur the purpose of _address assignment_.

> Since the PD is acquired using DHCPv6, why should the CE WAN initiate DHCPv6 if no DHCPv6 services are available?  So why not stick with Chris’ proposal of the changed WPD-4 in rfc6204bis?

DHCPv6 PD does not use the M/O flags. neither should it, they are overloaded as it is.
DHCPv6 PD is a protocol between _routers_ from a pure DHCPv6 sense, a requesting router is not required to do any of the host functions specified in 6204. in addition we still want to allow for the Router discovery and DHCP PD processing to be done in parallel.

> I do have a question for Chris.  Why is Ralph’s MAX_SOLO_RT DHCPv6 draft not sufficient to mitigate the pounding of the DHCPv6 server by a CE router asking for PD when the SP hasn’t enabled PD services on the DHCPv6 server? 

Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 19 Mar 2012 06:20:04 -0500

Ole,

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Trøan
Sent: Monday, March 19, 2012 12:01 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]; Ron Bonica; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>DHCPv6 PD does not use the M/O flags. neither should it, they are overloaded as it is.

There is no IETF document that says DHCPv6 PD does not use the M flags.  I am not sold on the overloading just yet.  M=0, O=0 in RFC 4861 indicates no DHCPv6 services are available.

>DHCPv6 PD is a protocol between _routers_ from a pure DHCPv6 sense, a requesting router is not required to do any of the host functions specified in >6204. 

The requesting router sent a DHCPv6 SOLICIT asking for an address (IA_NA IA_Address) and also an IA_PD.  The requesting router just performed a host addressing function with the IA_NA option in the SOLICIT.  The most common protocol running between two routers is routing.  Just because IA_PD acquisition runs between two routers doesn't mean the M and the O bits can be so blatantly ignored because DHCPv6 is used to acquire the IA_PD.  Specifically, the DHCPv6 client in the requesting router is served by the DHCPv6 server in the delegating router. 

>in addition we still want to allow for the Router discovery and DHCP PD processing to be done in parallel.

Router discovery fails.  Does it now even make sense to initiate DHCPv6 PD processing because DHCPv6 processing is likely to fail too.  If DHCPv6 does not fail and a PD is acquired, the requesting router does not have a default router which is learnt from the ND RA.  Now the requesting router cannot send packets upstream.  What good is such a setup?

Hemant

---

From: Ole Trøan <[email-masked]>
Date: Tue, 20 Mar 2012 12:36:50 +0100

> There is no IETF document that says DHCPv6 PD does not use the M flags.  I am not sold on the overloading just yet.  M=0, O=0 in RFC 4861 indicates no DHCPv6 services are available.

more correctly there is no document that says PD uses the M flag. the M flag is the "Managed address configuration " flag.

> The requesting router sent a DHCPv6 SOLICIT asking for an address (IA_NA IA_Address) and also an IA_PD.  The requesting router just performed a host addressing function with the IA_NA option in the…

they serve as hints, I doubt that can be considered "blatantly ignored".

> Router discovery fails.  Does it now even make sense to initiate DHCPv6 PD processing because DHCPv6 processing is likely to fail too.  If DHCPv6 does not fail and a PD is acquired, the requesting…

router discovery is only one of many ways of doing router discovery. imagine a PPP link, where there isn't a need for router discovery at all.

Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 20 Mar 2012 07:34:23 -0500

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Trøan
Sent: Tuesday, March 20, 2012 7:37 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]; Ron Bonica; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>router discovery is only one of many ways of doing router discovery. imagine a PPP link, where there isn't a need for router discovery at >all.

What specific deployment is the PPP link in?  Cellular, DSL broadband, backbone routers?  More details on L2/L3 topology, addressing of CE routers and details deployment would help.  A pointer to an IETF document describing the deployment would be even better.  For example PPP does use an RA in Softwire Hub and Spoke.

http://tools.ietf.org/html/rfc5571

Hemant

---

From: Chris Grundemann <[email-masked]>
Date: Tue, 20 Mar 2012 14:36:18 -0600

On 3/20/12 5:36 AM, "Ole Trøan" <[email-masked]> wrote:

>> There is no IETF document that says DHCPv6 PD does not use the M flags.
>> I am not sold on the overloading just yet.  M=0, O=0 in RFC 4861
>>indicates no DHCPv6 services are available.
>
>more correctly there is no document that says PD uses the M flag. the M
>flag is the "Managed address configuration " flag.

Yes, and the O flag is the "Other configuration" flag. PD is certainly
other DHCPv6 configuration information. In fact, RFC 4861 is quite clear
on this point, it states: "If neither M nor O flags are set, this
indicates that no information is available via DHCPv6." (emphasis on 'NO
information')

Cheers,
~Chris

---

From: Chris Grundemann <[email-masked]>
Date: Tue, 20 Mar 2012 15:59:29 -0600

The current versions (-07 and -08 alike) of this document contain much
needed updates to the IPv6 customer edge router requirements, especially
considering the impending World IPv6 Launch event. This is certainly an
important document and its content is ready to move forward.

As others have already noted, there are potential issues in this space
which will likely need to be addressed in the future but our best course
of action is to move the current changes in 6204bis forward and circle
back when appropriate with a 6204ter to address them. In addition to the
items already mentioned, it is possible that Homenet will produce new
requirements in the future that will need to be incorporated into a
6204ter as well. Holding up 6204bis at this stage is counter productive.

Cheers,
~Chris

On 3/8/12 2:30 PM, "Fred Baker" <[email-masked]> wrote:

>This is to initiate a two week working group last call of
>draft-ietf-v6ops-6204bis. Please read it now. If you find nits (spelling
>errors, minor suggested wording changes, etc), comment to the authors; if
>you find greater issues, such as disagreeing with a statement or finding
>additional issues that need to be addressed, please post your comments to
>the list. The draft will be on the agenda at IETF 83, and I would like to
>send the authors home with a work plan to complete it if it is not to the
>WG's liking.
>
>We are looking specifically for comments on the importance of the
>document as well as its content. If you have read the document and
>believe it to be of operational utility, that is also an important
>comment to make.

---

From: Ole Trøan <[email-masked]>
Date: Wed, 21 Mar 2012 20:16:49 +0100

> indicates that no information is available via DHCPv6." (emphasis on 'NO

no, and this was certainly not the spirit that 3633 was written in.
can we please not discuss the M/O flags again?

cheers,
Ole

---

From: Hans Liu <[email-masked]>
Date: Thu, 22 Mar 2012 09:01:19 +0800

+1

If someone again asks me what is the challenge for CE vendors, I might
tell them because we don't even have those most fundamental standard
settled, such as M/O flags!?

Sincerely,
Hans

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Mar 2012 11:03:08 +0000

> can we please not discuss the M/O flags again?

I think this is a good intention to have, but the fact is that how this all works isn't clearly specified.   If your response is correct, and I think it's reasonable to say that it is, then it needs to be stated explicitly somewhere where people will see it.

RFC3633 doesn't refer to the M and O bits at all, but does refer to RFC3315 for guidance on how to start.   Consequently, the reader is left free to decide which of several possible interpretations of how to behave with respect to the M and O bits is correct.   We have heard people give convincing arguments in favor of all three interpretations.   I think that you, as an author of the original document, should be treated as fairly authoritative on this question, but the fact is that if we want to resolve this debate, the right thing to do is reissue RFC3633 with the addition of a clear statement to the effect that the M and O bits are not considered when doing prefix delegation.

It would be good to do this sooner rather than later.

---

From: Ole Trøan <[email-masked]>
Date: Thu, 22 Mar 2012 12:31:39 +0100

Ted,

> It would be good to do this sooner rather than later.

RFC3633 specifies a protocol between two routers. it does say the requesting router should behave like a DHCP client, but it specifically does not say that the requesting router should behave like a host as defined in RFC4861.

the combination of 3315, 3633, 4861 creates no ambiguity in my view. (4861 states that routers set the M/O bits when sending RAs, but do not do anything with them).

the problem comes when RFC6204 defines the WAN interface behaving both as a RFC4861 host and router at the same time. which function is done in which context?

should 6204 be authoritative on that? given that this isn't a model either of 4861/3315 or 3633 or written according to.

cheers,
Ole

---

From: Tim Chown <[email-masked]>
Date: Thu, 22 Mar 2012 12:02:52 +0000

Hi,

Due to a typo in the draft name, this draft didn't hit Fred's automated WG tools, so the authors would like to raise the draft on the list now with a view to securing a slot in Paris to discuss its value and content.

In Taipei there was a comment in the WG session that there is no up-to-date v6ops guidance on enterprise networks, while other scenarios do have such texts.  So at the mic I invited people to join an effort to put something together.  There is a good breadth of experience across the people who stepped forward, and the result is available as 
	http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.txt

Does the WG think the subject matter of this draft is one we should pursue in the WG?  If so, is the structure and content appropriate?  We need some positive feedback and comments in order for Fred to schedule us time in Paris.

We have had a couple of people contact us off-list offering to help develop the content.  But we'd like some feedback from the WG before investing more time in doing so.  The -00 text is somewhat "rough", but we feel it could be polished into something quite useful for the community.

Tim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Mar 2012 12:13:49 +0000

> the combination of 3315, 3633, 4861 creates no ambiguity in my view. (4861 
> states that routers set the M/O bits when sending RAs, but do not do anything
> with them).

So what you are saying is that a person who is intimately familiar with all relevant documents will always, through logical derivation, come to the conclusion that you say is correct.   Even if this were true, it would be irrelevant: what matters is the conclusion that someone who reads RFC33633 comes to.   And since we have seen IETF participants draw conclusions other than the one you say is correct, we have clear evidence that the current specification is inadequate.

> should 6204 be authoritative on that? given that this isn't a model either of 4861/3315 or 3633 or written according to.

I don't think this is relevant.   If you think the right thing is for the router to ignore the M and O bits in the RA, then the document should say so, and should not leave it up to the reader to decide, based on  interpretation of various related, particularly when those documents do not all agree.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 22 Mar 2012 08:52:43 -0500

Perhaps for now an errata for 3633 stating that the M&O bits are not used for Prefix Delegation would be best?

This does also tie into the open issues for IA_NA/IA_PD for the CPE router ... does it wait for the RA before initiating DHCPv6 or should it do the IA_PD Solicit "immediately" (with an IA_NA if the RA was received with the M bit set). 

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Thursday, March 22, 2012 8:14 AM
To: Ole Trøan
Cc: [email-masked]; [email-masked]; Ronald Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

> the combination of 3315, 3633, 4861 creates no ambiguity in my view. 
> (4861 states that routers set the M/O bits when sending RAs, but do 
> not do anything with them).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Mar 2012 13:58:34 +0000

> Perhaps for now an errata for 3633 stating that the M&O bits are not used for Prefix Delegation would be best?

This may be all anyone has the energy to do, but errata are a very limited mechanism for addressing problems of this sort.   Most implementors aren't aware enough to read them, so their primary purpose is for standards activity--either standards referring to them, or as a record to use when doing a future update of the standard with the error.   It's still fairly early days, so clarifying these documents now by reissuing them, rather than writing errata, will be fairly effective.   The longer we wait, the less effective it will be.

---

From: Rajiv Asati <[email-masked]>
Date: Thu, 22 Mar 2012 10:25:20 -0400

+1

-----Original Message-----
From: Ted Lemon <[email-masked]>
Date: Thu, 22 Mar 2012 13:58:34 +0000
To: "Bernie Volz (volz)" <[email-masked]>, Ole Trøan <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Ronald Bonica <[email-masked]>
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>> Perhaps for now an errata for 3633 stating that the M&O bits are not
>>used for Prefix Delegation would be best?
>
>This may be all anyone has the energy to do, but errata are a very
>limited mechanism for addressing problems of this sort.   Most
>implementors aren't aware enough to read them, so their primary purpose
>is for standards activity--either standards referring to them, or as a
>record to use when doing a future update of the standard with the error.
> It's still fairly early days, so clarifying these documents now by
>reissuing them, rather than writing errata, will be fairly effective.
>The longer we wait, the less effective it will be.

---

From: Chris Grundemann <[email-masked]>
Date: Thu, 22 Mar 2012 08:36:35 -0600

Ole,

> RFC3633 specifies a protocol between two routers. it does say the requesting router should behave like a DHCP client, but it specifically does not say that the requesting router should behave like…

It also does not say that it should not behave in that way.

> the problem comes when RFC6204 defines the WAN interface behaving both as a RFC4861 host and router at the same time. which function is done in which context?

It appears clear that client/host functions are primarily WAN facing
and server/router functions are primarily LAN facing, this facilitates
predictable behavior in ISP networks where customers may connect
either customer edge routers or hosts to the service provider network.

> should 6204 be authoritative on that? given that this isn't a model either of 4861/3315 or 3633 or written according to.

Yes.

In several cases 6204/6204bis provides more specific requirements than
the standards it points to. Understanding that 3633 was not written to
specifically address customer edge routers, we are now adding a needed
requirement which does not contradict any previously documented
requirements.

Cheers,
~Chris

-- 
@ChrisGrundemann
http://chrisgrundemann.com

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 22 Mar 2012 10:54:12 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Trøan
Sent: Thursday, March 22, 2012 7:32 AM
To: Ted Lemon
Cc: [email-masked]; [email-masked]; Ronald Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>RFC3633 specifies a protocol between two routers. it does say the requesting router should behave like a DHCP client, but it specifically does not say that the >requesting router should behave like a host as defined in RFC4861.

I already said once to the mailer that the protocol between two routers for RFC 3633 uses DHCPv6 and the requesting router uses a DHCPv6 client.  Likewise the delegating router uses a DHCPv6 server.  I have also said, that the router RA provides the default router to the requesting router - the reason is because DHCPv6 does not support default router information provision.  Neither should DHCPv6 because we still could not resolve what if DHCPv6 and IPv6 ND RA both provide the default router and there is a conflict?  Who wins?

>the combination of 3315, 3633, 4861 creates no ambiguity in my view. (4861 states that routers set the M/O bits when sending RAs, but do not do anything with >them).

Not quite.  I am not debating the M or the O bit which is a decade-long rat-hole.  It's the case when both the bits are zero is what I am focusing the discussion on.  When M and O bits are both zero, then IPv6 nodes should follow RFC4861 that says, "indicates no dhcpv6 services are available".  Thus only for the case of M and O being zero, the CE router MUST not initiate DHCPv6. 

Please hold off any Errata to RFC 3633 or any new document.  Thus

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 22 Mar 2012 22:55:11 -0500

Chris,

-----Original Message-----
From: Chris Grundemann [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2012 4:36 PM
To: Ole Trøan; Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]; Ronald Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>information')

Not quite.  The O flag is to obtain information using stateless DHCPv6 - see http://tools.ietf.org/rfc/rfc3736.txt.

PD acquisition is a stateful DHCPv6 procedure or RFC 3633 has to also clarify if PD acquisition is supported via both stateful and stateless DHCPv6.  We have discussed such a clarification with Ralph Droms and Ole in the past - don't remember the outcome.  Further, a DHCPv6 client includes the IA_NA and the IA_PD option in the DHCPv6 SOLICIT.  IA_NA IA_Address acquisition is a stateful DHCPv6 operation and now if PD acquisition is a stateless operation, what if the DHCPv6 server the SOLICIT is going to is only stateless (and if rfc3633 supports stateless dhcpv6 operation?). The IA_NA is not obtained from such a server.   I hope it's clear now the kind of DHCPv6 client and server issues one has.  In the kind of network I develop products for, I so do prefer that 120,000 DHCPv6 clients on my router relay agent do issue SOLICIT with both IA_NA and the IA_PD so that I save upstream bandwidth or alleviate congestion.  The DHCPv6 server in our deployment also better support stateful and stateless services in one server.  

I keep hearing of new corner cases in the DHC WG related to DHCPv6 server for the PD being separate from the server that allocates IA_NA's.  It's fine to work out such corner cases, but a gentle reminder that the broadband networks, IMHO, need consolidated options in a DHCPv6 SOLICIT.

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Fri, 23 Mar 2012 23:49:05 +0100

The current description of 6rd and ds-lite in 6204bis dangerously avoids the issue of how to gracefully transition from a native IPv4 to Dual-Stack lite, in particular with a retail CPE vs. ISP-managed CPE. The same is true for graceful sunsetting of 6rd to native IPv6.

Ole and I captured the rather heated discussion on v6ops a couple of months back in the following document: draft-townsley-troan-ipv6-ce-transitioning-02

I believe the problem here is that there is demand from operators to include DS-Lite and 6rd in this document is very strong, yet the implementation details have not been specified well enough to allow DS-Lite and Native IPv4 or Native IPv6 and 6rd to coexist in a consistent and non-distruptive manner with one another. This is fairly dangerous as it will undoubtedly lead to highly variant implementation. I can easily see this sinking the ability to incrementally deploy DS-Lite in a retail CPE setting, for example. It could also be detrimental to sunsetting of 6rd.

I'd be happy to present the issue to v6ops. I think the issue needs to be voiced (as the draft appeared since the last meeting, it has not had airtime in any IETF meeting yet, despite us revving a couple of times). 

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 23 Mar 2012 19:02:05 -0500

draft-townsley-troan-ipv6-ce-transitioning-02 is not an RFC yet nor in
the IESG review and thus this document has to be punted to rfc6204ter.
Further the tech described in the document should be a Standard Tracks
document.  Chris Donley who represents all Cable MSO's from Cablelabs
has expressed an urgent desire to get rfc6204bis out as an RFC by
December 2011.  Barbara Stark has expressed a similar desire.  Further
FT Orange and Telecom Italia have expressed the urgency too.

If this email can humbly be considered for closure, one can avoid a
lengthy discussion at Paris during the presentation of rfc6204bis in
v6ops. For a much later consideration, which mailing list is
draft-townsley-troan-ipv6-ce-transitioning-02 being discussed and where
are the review comments?

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Townsley
Sent: Friday, March 23, 2012 6:49 PM
To: Fred Baker (fred)
Cc: [email-masked]; [email-masked]; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

The current description of 6rd and ds-lite in 6204bis dangerously avoids
the issue of how to gracefully transition from a native IPv4 to
Dual-Stack lite, in particular with a retail CPE vs. ISP-managed CPE.
The same is true for graceful sunsetting of 6rd to native IPv6.

Ole and I captured the rather heated discussion on v6ops a couple of
months back in the following document:
draft-townsley-troan-ipv6-ce-transitioning-02

I believe the problem here is that there is demand from operators to
include DS-Lite and 6rd in this document is very strong, yet the
implementation details have not been specified well enough to allow
DS-Lite and Native IPv4 or Native IPv6 and 6rd to coexist in a
consistent and non-distruptive manner with one another. This is fairly
dangerous as it will undoubtedly lead to highly variant implementation.
I can easily see this sinking the ability to incrementally deploy
DS-Lite in a retail CPE setting, for example. It could also be
detrimental to sunsetting of 6rd.

I'd be happy to present the issue to v6ops. I think the issue needs to
be voiced (as the draft appeared since the last meeting, it has not had
airtime in any IETF meeting yet, despite us revving a couple of times). 

- Mark

draft-ietf-v6ops-6204bis. Please read it now. If you find nits (spelling
errors, minor suggested wording changes, etc), comment to the authors;
if you find greater issues, such as disagreeing with a statement or
finding additional issues that need to be addressed, please post your
comments to the list. The draft will be on the agenda at IETF 83, and I
would like to send the authors home with a work plan to complete it if
it is not to the WG's liking.

---

From: Mark Townsley <[email-masked]>
Date: Sat, 24 Mar 2012 08:36:16 +0100

> draft-townsley-troan-ipv6-ce-transitioning-02 is not an RFC yet nor in

Stating the obvious

> the IESG review and thus this document has to be punted to rfc6204ter.

Is there even consensus that a 6204ter document should exist at all? I certainly hope not. 

> document.  

Perhaps. The problem is that the requirements placed in 6204bis require some version of this tech (several options are identified, there is one we prefer of course, but I argue that at least one by definition must be chosen - 6204 bis just ignores it). 

> Chris Donley who represents all Cable MSO's from Cablelabs

In the IETF, Chris Donley represents Chris Donley.

> FT Orange and Telecom Italia have expressed the urgency too.

As above.

> draft-townsley-troan-ipv6-ce-transitioning-02 being discussed and where

It's targeted at v6ops, but we made a mistake when we named it obviously. 

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 24 Mar 2012 04:31:27 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Friday, March 23, 2012 8:02 PM
To: Mark Townsley; Fred Baker (fred)
Cc: [email-masked]; [email-masked]; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>For a much later consideration, which mailing list is

>are the review comments?

Sorry that I just read Fred's email about 184 emails on this topic.  I
got thrown off seeing no v6ops in the draft name above.  I have seen the
discussions on 6rd sunsetting but those are mostly general discussions.
As Barbara said an SP deploys 6rd or DS-Lite, so why bother for 6rd,
DS-Lite, and native dual-stack coexistence?  

The document is incomplete.  Let's consider only IPv6 for now. There is
an SRIB, DFIB, and a Policy Table.  Additionally the CE does have a FIB.
Where are the details for how does the FIB interface with the SRIB,
DFIB, and the Policy Table?  There are 24 combinations (4!) of results
between the FIB, SRIB, DFIB, and the Policy Table.  Which combination is
used to forward a packet?  Some conclusions below.

(a)    it is questionable if the work is even needed because the SP
deploys one of 6rd and DS-Lite and one needs simpler 6rd sunsetting or
DS-Lite sunsetting, and 

(b)    draft-townsley-troan-ipv6-ce-transitioning-02 is not ready to be
adopted as a WG document.

Rfc6204bis can't be held up due to
draft-townsley-troan-ipv6-ce-transitioning-02. 

Further, isn't draft-townsley-troan-ipv6-ce-transitioning-02 specifying
technology or is there another document that covers the technology in
more detail?  Technology documents need to move to a different WG.  

Hemant

---

From: Fred Baker <[email-masked]>
Date: Sat, 24 Mar 2012 12:16:34 +0100

On Mar 24, 2012, at 10:31 AM, Hemant Singh (shemant) wrote:

> Further, isn’t draft-townsley-troan-ipv6-ce-transitioning-02 specifying technology or is there another document that covers the technology in more detail?  Technology documents need to move to a different WG. 

I'm reading your statement above, and in other email reading statements by someone using the same email address that go into some detail on the implications of binary flags in messages. I'm wondering where the line is drawn and why one draws it.

I have asked a selection of ADs and WG Chairs to weigh in on where the document should be discussed; if someone comes back to Joel and I with "this obviously belongs in <>", we'll send it there or send the relevant subset there. Personally, I think it falls within the charter of operational procedures used in IPv6 networks.

Where I draw the line on the normative reference that Ole and Mark would like is how well baked the proposed procedures are. We will determine that Monday.

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Sat, 24 Mar 2012 12:26:35 +0100

Fred - not meaning to suggest this topic isn't important...but it's way too nice a day to give the issue the consideration it deserves.   So, I'll post a response, but likely not until tomorrow when I'll be sequestered indoors most of the day, anyway.

- Ralph

---

From: Mark Townsley <[email-masked]>
Date: Sat, 24 Mar 2012 12:33:19 +0100

On Mar 24, 2012, at 12:26 PM, Ralph Droms (rdroms) wrote:

> it's way too nice a day to give the issue the consideration it deserves.   

Enjoy Spring in Paris, Ralph. Wish I was :-)

> So, I'll post a response, but likely not until tomorrow when I'll be sequestered indoors most of the day, anyway.

FWIW, it seem the chairs have given airtime for us to talk about this Monday morning if you want to wait until you have heard the real-time part of the discussion.

- Mark

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Sat, 24 Mar 2012 12:40:13 +0100

> Enjoy Spring in Paris, Ralph. Wish I was :-)

The weather is a little better than when I was here for the IPv6 World Congress...

> FWIW, it seem the chairs have given airtime for us to talk about this Monday morning if you want to wait until you have heard the real-time part of the discussion.

Why do I need to hear all the data before giving an opinion?

- Ralph

---

From: Mark Townsley <[email-masked]>
Date: Sat, 24 Mar 2012 12:52:53 +0100

On Mar 24, 2012, at 12:40 PM, Ralph Droms (rdroms) wrote:

> The weather is a little better than when I was here for the IPv6 World Congress…

Yes, that was embarrassing. We're trying to make up for it. 

> Why do I need to hear all the data before giving an opinion?

No comment.

- Mark

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 26 Mar 2012 13:41:39 +0200

IPv6 WG,

I would like to kick off some comments on this draft for other group
members to comment.

I do think (Bias noted) that this material is useful for Enterprises who
need to being and/or move their IPv6 deployments.  Many (of those I have
worked with thus far) are bogged down with personnel who are overwhelmed
with what it may take to get IPv6 moving on their networks.

The draft breaks the challenge down by areas of focus (rolled into
"Phases") which can help put this large challenge into bite size chunks
for them. The draft also provides some valid contextual information around
IPv6 and highlights areas which should be looked at.

Given the good momentum we now have in the operator space, it would be
good to see this move forward into the Enterprise space.  I think such
documents can help many of those still waffling (too many to count) to
start acting.

Regards,

Victor K

On 12-03-22 8:02 AM, "Tim Chown" <[email-masked]> wrote:

>Hi,
>
>Due to a typo in the draft name, this draft didn't hit Fred's automated
>WG tools, so the authors would like to raise the draft on the list now
>with a view to securing a slot in Paris to discuss its value and content.
>
>In Taipei there was a comment in the WG session that there is no
>up-to-date v6ops guidance on enterprise networks, while other scenarios
>do have such texts.  So at the mic I invited people to join an effort to
>put something together.  There is a good breadth of experience across the
>people who stepped forward, and the result is available as
>Does the WG think the subject matter of this draft is one we should
>pursue in the WG?  If so, is the structure and content appropriate?  We
>need some positive feedback and comments in order for Fred to schedule us
>time in Paris.
>
>We have had a couple of people contact us off-list offering to help
>develop the content.  But we'd like some feedback from the WG before
>investing more time in doing so.  The -00 text is somewhat "rough", but
>we feel it could be polished into something quite useful for the
>community.
>
>Tim
>