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

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Thu, 13 Oct 2011 23:50:34 +0300

Just to add to everyone else that expressed the desire to see
DS-Lite in this, i totally agree with them.

We recently run an RFP looking for IPv6 CPEs from various vendors
and nobody of them had a official version supporting it.

We even got answers from vendors (that are very active inside IETF),
that they are not planning to implement it.

So having a standard RFC "pushing" them in that direction is always
welcome.

Regarding PCP, i would also like to have it as a basic requirement.
But i can live with the assurance that when finished, it will be
added (maybe somewhere else).

Currently, we are planning to enable DS-Lite only to subscribers
that have all port forwarding methods disabled in their CPE, so we
can "bypass" a need for it.

But as the number of subscribers grows, we'll surely need a way to
make port forwarding (+other stuff) work in CGN.

As a sidenote, i WOULD like to see in this draft just a section
referring to PCP (like 8.5 in RFC 6333), if PCP requirements are
going to be left out from this.

Also, i would like to make some other comments on
draft-ietf-v6ops-6204bis-00.

In G-2 & L-14, ICMP should be changed to ICMPv6.

6RD-3: If the CE router implements 6rd functionality, it MUST allow
the user to specify whether all IPv6 traffic goes to the 6rd
Border Relay, or whether other destinations within the same
6rd domain are routed directly to those destinations.

6RD-3: If the CE router implements 6rd functionality, it MUST allow
the user to specify whether all IPv6 traffic goes to the 6rd
Border Relay, or whether IPv6 traffic towards other destinations within the same
6rd domain is routed directly to those destinations.

More specifically,
Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at
the IPv6 CE Router and sends it to a Service Provider Address Family
Translation Router (AFTR).

More specifically,
Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at
the IPv6 CE Router and sends it to a Service Provider Address Family
Transition Router (AFTR).

DLW-2: If the IPv6 CE Router implements DS-Lite functionality, the
CE Router MUST support using a DS-Lite DHCPv6 option
[I-D.ietf-softwire-ds-lite-tunnel-option] to configure the
DS-Lite tunnel. The IPv6 CE Router MAY use other mechanisms
to configure DS-Lite parameters. Such mechanisms are outside
the scope of this document.

DLW-2: If the IPv6 CE Router implements DS-Lite functionality, the
CE Router SHOULD support using a DS-Lite DHCPv6 option
[RFC 6334] to configure the
DS-Lite tunnel. The IPv6 CE Router MAY use other mechanisms
to configure DS-Lite parameters. Such mechanisms are outside
the scope of this document.

RFC 6333 says that the DS-Lite DHCPv6 option is a SHOULD.

"7.1. Normative References" should be updated with the RFC number
too

Run the following four in parallel to provision CPE router
connectivity to the Service Provider:

1. Initiate IPv4 address acquisition.

2. Initiate IPv6 address acquisition as specified by [RFC6204].

3. If 6rd is provisioned, initiate 6rd.

4. If DS-Lite is provisioned, initiate DS-Lite.

I can't see how all four can run in parallel.

Run the following two in parallel to provision CPE router
connectivity to the Service Provider:

1. Initiate IPv4 address acquisition.

2. Initiate IPv6 address acquisition as specified in Section 4.2.

Then,

If IPv4 address acquisition is successful and 6rd is provisioned, initiate 6rd.

If IPv6 address acquisition is successful and DS-Lite is provisioned, initiate DS-Lite.

Lastly, i would also like to have the following under "4.5. Security
Considerations". Unless we are leaving this functionality to the
AFTR/BR (although i couldn't find anything relevant; PCP?).

S-3:  The IPv6 CE router MUST support the configuration
of a common filtering behavior, regardless of the interface
type that traffic is coming through (native or through a
transition/tunneling technology).

--
Tassos

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 13 Oct 2011 19:18:23 -0500

Tassos,

Thanks so much for the great catches in the text!  Please see in line below.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tassos Chatzithomaoglou
Sent: Thursday, October 13, 2011 4:51 PM
To: [email-masked]; [email-masked]
Subject: [v6ops] new draft: draft-ietf-v6ops-6204bis

>In G-2 & L-14, ICMP should be changed to ICMPv6.

Will do.

   >        6rd domain is routed directly to those destinations.  

Will do.

>   Transition Router (AFTR).

Will do.

 >          [I-D.ietf-softwire-ds-lite-tunnel-option <http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-00#ref-I-D.ietf-softwire-ds-lite-tunnel-option> ] to configure the

 >          the scope of this document.

Will do.

>"7.1. Normative References" should be updated with the RFC number too

Agree.

 
>   2.  Initiate IPv6 address acquisition as specified by [RFC6204 <http://tools.ietf.org/html/rfc6204> ].

>I can't see how all four can run in parallel.

To us authors we assumed anyone who understands the transition techs would understand 3 has to wait until 1 succeeds and 4 has to wait until 2 succeeds.  However, as we can see from review (from several people) the text could use more clarification.  Thus we are changing the text to be more descriptive.   Early new text was sent out today.   Please see the email with new text at the URL below.

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

Final text is still pending.  We will try and finalize the text ASAP.

>Lastly, i would also like to have the following under "4.5. Security Considerations". Unless we are leaving this functionality to the AFTR/BR >(although i couldn't find anything relevant; PCP?).

>S-3:  The IPv6 CE router MUST support the configuration of a common filtering behavior, regardless of the >interface type that traffic is coming through (native or through a transition/tunneling technology).

Will have to think about this one.  S-2 already mentions ingress filtering.  We could modify S-2 to include some text from your suggestion above.   

Thanks much,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 13 Oct 2011 19:59:49 -0500

>As a sidenote, i WOULD like to see in this draft just a section referring to PCP (like 8.5 in RFC 6333), if PCP requirements are going to be >left out from this.

Will discuss with the Chair and the cpe design team and see what we can do for this one.

Thanks,

Hemant

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 18:23:26 -0700

> -----Original Message-----
> Sent: Thursday, October 13, 2011 1:51 PM
> Just to add to everyone else that expressed the desire to see DS-Lite
> in this, i totally agree with them.
> We recently run an RFP looking for IPv6 CPEs from various vendors and
> nobody of them had a official version supporting it.
> Regarding PCP, i would also like to have it as a basic requirement. But
> i can live with the assurance that when finished, it will be added
> (maybe somewhere else).
> Currently, we are planning to enable DS-Lite only to subscribers that
> have all port forwarding methods disabled in their CPE, so we can
> "bypass" a need for it.
> But as the number of subscribers grows, we'll surely need a way to make
> port forwarding (+other stuff) work in CGN.

PCP is not just about IPv4 and is not just about CGN.

Ignore IPv4 for a moment.  Let's concentrate on IPv6.

For IPv6, if the CPE going to comply with RFC6092 (Simple CPE
Security), incoming unsolicited traffic will be blocked.  If the
IPv6 host is hoping to run an Internet-facing server, the host and
and CPE will need to either:
  (1) implement UPnP IGD 2.0 (which supports IPv6 firewall), or
  (2) implement PCP (which supports IPv6 firewall), or 
  (3) the user will have to configure exceptions manually in 
      their CPE (e.g., using web pages).  

I think PCP is the best answer of those three, because it works
in all anticipated mixes of technology that may be deployed on
a particular network for that network's IPv6 transition, 
including NAT64, NPTv6, NAT46, NAT44, etc.

-d

> referring to PCP (like 8.5 in RFC 6333), if PCP requirements are going
> to be left out from this.
> 
> 
> 
> Also, i would like to make some other comments on draft-ietf-v6ops-
> 6204bis-00.
> 
> 
> 	           [I-D.ietf-softwire-ds-lite-tunnel-option
> <http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-00#ref-I-D.ietf-
> softwire-ds-lite-tunnel-option> ] to configure the
> S-3:  The IPv6 CE router MUST support the configuration of a common
> filtering behavior, regardless of the interface type that traffic is
> coming through (native or through a transition/tunneling technology).
> 
> 
> 
> --
> Tassos

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Fri, 14 Oct 2011 10:43:02 +0300

> including NAT64, NPTv6, NAT46, NAT44, etc.

Dan,

I had the impression that for Internet-facing servers the best (in terms of 100% correct 
behavior) answer was No 3; configure it manually on the CPE.
At least this is based on my experience on IPv4 CPEs (haven't seen a fully working 
firewall on IPv6 CPEs).
On other hand, i am more of a manual config guy (i want to know what's open and what's 
not), so maybe i am missing the typical subscriber's "best" answer.

Imho seeing PCP client support in hosts and applications might take a while. I was hoping 
for PCP on the CPE WAN side as a first. I see it as more urgent.

btw, quoting from draft-ietf-pcp-base-14, "Introdution":

PCP is designed to be implemented in the context
    of both Carrier-Grade NATs (CGNs) and small NATs (e.g., residential
    NATs).  PCP allows hosts to operate servers for a long time (e.g., a
    webcam) or a short time (e.g., while playing a game or on a phone
    call) when behind a NAT device, including when behind a CGN operated
    by their Internet service provider.

Although, IPv4/IPv6 firewalls are referenced further inside the text, i would like to see 
them here too.

--
Tassos

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Oct 2011 15:04:21 -0700

> From: Tassos Chatzithomaoglou [mailto:[email-masked]]
> Sent: Friday, October 14, 2011 12:43 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]
> Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis
> 
> 
> >> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of Tassos Chatzithomaoglou
> and
> But
> that
> make
> At least this is based on my experience on IPv4 CPEs (haven't seen a
> fully working firewall on IPv6 CPEs).

The typical subscriber doesn't have any clue how to configure their
CPE, nor understand the need to do so.  Think of Joe Sixpack, Grandma,
or the actors on TV commercials as typical subscribers -- not IETFers
who are smart enough to be involved in IPv6.

> for PCP on the CPE WAN side as a first. I see it as more urgent.

It's all in what Apple/Linux/Microsoft add to their products.

> Although, IPv4/IPv6 firewalls are referenced further inside the text, i

Ok, will be mentioned in -15 up front.  Thanks.

-d

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 14 Oct 2011 17:05:11 -0500

Tassos,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Thursday, October 13, 2011 8:18 PM
To: Tassos Chatzithomaoglou; [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

>>S-3:  The IPv6 CE router MUST support the configuration of a common filtering behavior, regardless of the >interface type that traffic is coming through >>(native or through a transition/tunneling technology).

>Will have to think about this one.  S-2 already mentions ingress filtering.  We could modify S-2 to include some text from your suggestion above.   

How can the  device have a common filtering behavior for tunneled traffic vs. native traffic?    The rfc6204bis document already references RFC 6092 that discusses copious security for native and tunneled transport.  One key recommendation for security related to tunnels is prescribed in RFC 6169 which is to have tunneled traffic not cross border routers.  Both 6rd and DS-Lite tunnels terminate within the boundary of the SP secured domain.   Thus I don’t see a need for adding any other text related to security in the rfc 6204bis document yet.

Thanks,

Hemant

---

From: Doug Barton <[email-masked]>
Date: Fri, 14 Oct 2011 16:22:51 -0700

On 10/14/2011 15:04, Dan Wing wrote:
> CPE, nor understand the need to do so. 

... and to repeat something that all-too-often gets left out of the
analysis, they shouldn't have to understand either bit (why or how).

The Internet passed the tipping point into mass-market consumerism 10?
15 years ago? Continuing to design protocols that require users to both
know what knobs to twiddle and how/why to twiddle them is epic fail in
the making.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sat, 15 Oct 2011 02:58:42 +0300

Hemant Singh (shemant) wrote on 15/10/2011 01:05:

Tassos,

From:
[email-masked] [mailto:[email-masked]] On
Behalf Of Hemant Singh (shemant)

To: Tassos Chatzithomaoglou; [email-masked];
[email-masked]

Subject: Re: [v6ops] new draft:
draft-ietf-v6ops-6204bis

>>Lastly, i would also like
to have the following under "4.5. Security Considerations".
Unless we are leaving this functionality to the AFTR/BR >(although i couldn't find
anything relevant; PCP?).

>>S-3:  The IPv6 CE router MUST
support the configuration of a common filtering behavior,
regardless of the >interface type that traffic is
coming through >>(native or through a
transition/tunneling technology).

>Will have to think about this one.
S-2 already mentions ingress filtering.  We could modify S-2
to include some text from your suggestion above.

How
can the  device have a common filtering behavior for
tunneled traffic vs. native traffic?    The rfc6204bis
document already references RFC 6092 that discusses copious
security for native and tunneled transport.  One key
recommendation for security related to tunnels is prescribed
in RFC 6169 which is to have tunneled traffic not cross
border routers.  Both 6rd and DS-Lite tunnels terminate
within the boundary of the SP secured domain.   Thus I don’t
see a need for adding any other text related to security in
the rfc 6204bis document yet.

Thanks,

Hemant

Hemant,

Since the CPE is also a tunnel endpoint, i believe ingress filtering
of tunneled traffic should be implemented after the
decapsulation of the traffic, before reaching the LAN.

i.e. in case of DS-Lite, in the ingress direction, after the IPv6
tunnel header is removed, IPv4 traffic should be inspected like it
would be if it was coming from an IPv4 native interface. Unless the
IPv6 firewall can inspect IPv4inIPv6 packets too....or maybe i'm
asking too much from the CPE vendors.

PS: I guess we won't need to worry about this, if we leave it to the
PCP server on the AFTR.

Regards,

Tassos

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 14 Oct 2011 19:03:59 -0500

From: Tassos Chatzithomaoglou [mailto:[email-masked]] 
Sent: Friday, October 14, 2011 7:59 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

>Since the CPE is also a tunnel endpoint, i believe ingress filtering of tunneled traffic should be implemented after the decapsulation of the traffic, before reaching the LAN.
>i.e. in case of DS-Lite, in the ingress direction, after the IPv6 tunnel header is removed, IPv4 traffic should be inspected like it would be if it was coming from an IPv4 native interface. 

Ah, certainly!  I assumed we were discussing inspecting tunneled traffic vs. native and that is why I was wondering.    I do think any security filter inside the CE router will inspect all IPv4 or IPv6 packets whether the packets were decapsulated from a tunnel or were native IP packets.  If this is not obvious, we can certainly consider adding a sentence to make this one blatantly clear.

Thanks,

Hemant

---

From: Fred Baker <[email-masked]>
Date: Fri, 14 Oct 2011 17:06:33 -0700

> including NAT64, NPTv6, NAT46, NAT44, etc.

I have no argument that PCP is a reasonable solution if you say it is. I haven't looked at it. But to my mind, a combination of a firewall protecting the network from traffic that it has no application to receive, and a protocol that an application can use to say "please permit {source/destination address/port, protocol} traffic in your ACL until <time> or for <time units>" makes a lot of sense. Just tell me that the protocol sends its requests to a multicast group, so that if there is no firewall it doesn't overload the network and if there is the firewall will have joined said multicast group.

That said, they tell me that in an IPv6 network there will be no need for this on the WAN side, as there will be no CGN. This draft is about the WAN side, and anything on the LAN side is in homenet...

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Oct 2011 17:43:13 -0700

> From: Fred Baker [mailto:[email-masked]]
> Sent: Friday, October 14, 2011 5:07 PM
> To: Dan Wing
> Cc: 'Tassos Chatzithomaoglou'; [email-masked]; draft-ietf-v6ops-
> [email-masked]
> I have no argument that PCP is a reasonable solution if you say it is.
> I haven't looked at it. But to my mind, a combination of a firewall
> protecting the network from traffic that it has no application to
> receive, and a protocol that an application can use to say "please
> permit {source/destination address/port, protocol} traffic in your ACL
> until <time> or for <time units>" makes a lot of sense. Just tell me
> that the protocol sends its requests to a multicast group, so that if
> there is no firewall it doesn't overload the network and if there is
> the firewall will have joined said multicast group.

Right now, it just goes to the default router.  There is a planned
DHCP & DHCPv6 option to specify an alternate address 
(draft-bpw-pcp-dhcp), which could certainly be a multicast address.

> That said, they tell me that in an IPv6 network there will be no need
> for this on the WAN side, as there will be no CGN. This draft is about
> the WAN side, and anything on the LAN side is in homenet...

IPv6 networks are pretty likely to have a NAT64 (NAT64 is a "CGN64", 
really), until all interesting servers running IPv4-only today are
dual stack.  PCP would be running between that RFC6204bis CPE 
and the network's NAT64 device, like this:

  [IPv6-only host]---[RFC6204bis CPE]------[NAT64]--{IPv4 Internet}
                                     ^^^^^^
                                       PCP

-d

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sat, 15 Oct 2011 11:32:21 +0300

Hemant Singh (shemant) wrote on 15/10/2011 03:03:

From:
Tassos Chatzithomaoglou [mailto:[email-masked]]

Cc: [email-masked];

>Since the CPE is also a
tunnel endpoint, i believe ingress filtering of tunneled
traffic should be implemented after the decapsulation of
the traffic, before reaching the LAN.

>i.e. in case of
DS-Lite, in the ingress direction, after the IPv6 tunnel
header is removed, IPv4 traffic should be inspected like it
would be if it was coming from an IPv4 native interface.

Ah,
certainly!  I assumed we were discussing inspecting tunneled
traffic vs. native and that is why I was wondering.    I do
think any security filter inside the CE router will inspect
all IPv4 or IPv6 packets whether the packets were
decapsulated from a tunnel or were native IP packets.  If
this is not obvious, we can certainly consider adding a
sentence to make this one blatantly clear.

Thanks,

Hemant

I gave it a second thought and i'm thinking that without port
forwarding the chances of needing a firewall for decapsulated IPv4
traffic is low in case of DS-Lite.

RFC 4863 describes very nicely the perceived benefits of NAT (which
on this case will happen on the AFTR), and since we are not (are
we?) including any reference to port forwarding mechanisms, IPv4
attack vectors to the CPE through DS-Lite are low (but existent).

On the other hand, in the 6rd scenario, there is no (need for) NAT
happening on IPv6 traffic on the BR, so an IPv6 firewall for
filtering ingress decapsulated IPv4=>IPv6 traffic on the CPE is
surely needed.

Maybe, you would like to differentiate those scenarios in your text.

--

Tassos

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 18 Oct 2011 13:59:43 -0500

Tassos,

Sorry for the delayed reply.   Please see below.

Sent: Saturday, October 15, 2011 4:32 AM

>I gave it a second thought and i'm thinking that without port forwarding the chances of needing a firewall for decapsulated IPv4 traffic is low in case of DS->Lite. RFC 4863 describes very nicely the perceived benefits of NAT (which on this case will happen on the AFTR), and since we are not (are we?) including any >reference to port forwarding mechanisms, IPv4 attack vectors to the CPE through >DS-Lite are low (but existent).

If DS-Lite is enabled on the CE router, NAT has to be disabled on the CE router.  If there is no NAT running on the CE router, then port forwarding is not relevant. 

>On the other hand, in the 6rd scenario, there is no (need for) NAT happening on IPv6 traffic on the BR, so an IPv6 firewall for filtering ingress decapsulated >IPv4=>IPv6 traffic on the CPE is surely needed. Maybe, you would like to differentiate those scenarios in your text.

Certainly, we will mull over this suggestion and if we think text needs to be added, we will send out the text soon.

Regards,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 18 Oct 2011 15:39:00 -0500

Tassos,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Tuesday, October 18, 2011 3:00 PM
To: Tassos Chatzithomaoglou
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

> Certainly, we will mull over this suggestion and if we think text
needs to be added, we will send out the text soon.

This new bullet was added to the Security section in the -01 version
that was just posted to v6ops.

[When 6rd is enabled on the device, a firewall SHOULD provide the
capability to filter decapsulated packets from the 6rd tunnel.]

Hemant

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 18 Oct 2011 23:10:00 -0400

Hemant,

Sorry If I am getting to the game a bit late on this, but I had a question
on section 4.4.3 (Transition Technology Coexistence).

I kinda agree with some of the points in this section, but from what I
read here the suggestion is that we may have multiple transition
technologies running at the same time on the same home gateway.

Was this the intention of the text?

>From my point of view, I would not necessarily think that "turning
everything on" is a good idea.  I know the text provides facilities to
help manage some of the use cases (say running 6RD and Native IPv6 at the
same time), but this seems a bit complicated.

My question would be, if I have Native IPv6, why turn on 6RD at all?
Also, if I have a native IPv4 address, why turn on DS-Lite?  Whereas I
understand that doing it in this method may speed up connectivity to the
network (perhaps it's taking long for the IPv6 addressing to work and I
already have my IPv4 addressing complete with 6RD parameters), but is
there a lot of value in this?

Would a decision tree be warranted in this case?  I.e. Ask for both IPv6
and IPv4.. And if I get both, native dual stack is king.  If I get IPv4
only with the needed parameters then 6RD is good.  If I get IPv6 only with
parameters, then do DS-Lite.  This way I only need to enable the functions
and security modes needed for one of the three operating modes (NDS, 6RD,
DS-Lite).

The only hole is see here is if the operator provided an IPv4 address, and
IPv6 address but no PD came down.  I guess 6RD may be a good idea.

Perhaps I am alone in this line of thought.

Regards,

Victor K

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Wed, 19 Oct 2011 11:15:02 +0300

Hi Hemant,

Do you think it would be possible to add something about the MTU under "4.3.  LAN-Side 
Configuration"?

L-15: The IPv6 CE router SHOULD by default include the LAN MTU into its Router 
Advertisements.
       The activation of this behavior MAY be user-configurable. The LAN MTU SHOULD also 
be user-configurable.

There had been a similar talk 1 month ago, but i would like to see a recommended approach 
included.

--
Tassos

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Oct 2011 10:29:19 +0200

Tassos,

> Do you think it would be possible to add something about the MTU under "4.3.  LAN-Side Configuration"?
> 
> L-15: The IPv6 CE router SHOULD by default include the LAN MTU into its Router Advertisements.
>     The activation of this behavior MAY be user-configurable. The LAN MTU SHOULD also be user-configurable.
> 
> There had been a similar talk 1 month ago, but i would like to see a recommended approach included.

should the MTU be different than the default LAN link MTU and if so why?
should internal to the home communication also be restricted in MTU?
if the MTU is set e.g. equal to the WAN MTU, what do you do in the case of a routed home? how do you propagate the MTU inside the network?
what if there are conflicts?

unless you have good answers to these questions, I suggest we don't.

cheers,
Ole

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Wed, 19 Oct 2011 11:53:19 +0300

Ole,

> should the MTU be different than the default LAN link MTU and if so why?
It could be, in order to avoid PTB (packet too big) messages from the CE to the hosts for 
WAN communication (1500=>PTB=>1492=>ok).

> should internal to the home communication also be restricted in MTU?
That might by already restricted by the default LAN MTU.
I don't want that to be restricted, that's why the LAN MTU should be user-configurable.
> what if there are conflicts?
Although, a routed home might not be a typical subscriber's home, i would expect to have 
routed components handle this by their own.
I'm not asking for LAN MTU to be equal to WAN MTU specifically. I'm asking of advertising 
a MTU to the hosts, in order to avoid PTB messages, in case of WAN communication.
I'm also asking to be able to able to disable this, in order to have the hosts decide by 
their own.
> unless you have good answers to these questions, I suggest we don't.
Generally, i would like to have available as many options as possible, in order to cover 
most scenarios.
If you want to have 1492 everywhere in order to lower the fragmentation possibilities, 
then you should have this option.
If you want to have 1500 or 9000, knowing that you might need to do fragmentation, then 
you should also have these options.

I don't know how many IPv6 CPEs support (or will support) >1500 MTU on their LAN 
interfaces, but judging from the ones i have tried, none of them did (maybe it's because 
of their FE interfaces). In that case, i don't believe using a 1492 MTU vs a 1500 one will 
make a big difference for internal home communication.

Regards,
Tassos

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 19 Oct 2011 07:51:53 -0500

Victor,

-----Original Message-----
From: Victor Kuarsingh [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2011 11:10 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

>on section 4.4.3 (Transition Technology Coexistence).

No apologies needed and you are not late.

>Was this the intention of the text?

One reason is sunsetting. You have 6rd and you want to move to native
IPv6.  Thus there is likelihood of two technologies running
concurrently.  Note even when a CE router is rebooted to move to a new
IP technology (and run old one for a short period) the hosts behind the
CE router may not reset to also move to a new IP tech.   That is why the
CE router has to be prepared to run two IP techs concurrently. 

>My question would be, if I have Native IPv6, why turn on 6RD at all?

See above.

>Also, if I have a native IPv4 address, why turn on DS-Lite?  

Correct.  See bullet DLW-4 in the document. You were running DS-Lite and
are moving to native IPv4.  During sunsetting, both techs have to run
concurrently for a short period.  The periods are determined by DHCP
lease timeout of the roughly two hours of IPv6 prefix deprecation from
RFC 4862.

>Whereas I understand that doing it in this method may speed up
connectivity to the

>and IPv4.. And if I get both, native dual stack is king. 

If the device gets both IPv6 and a public IPv4, then the device goes to
dual-stack mode because then neither of DS-Lite nor 6rd is configured
nor provided in DHCPv4 or DHCPv6 messages.  This is possible with the
current text in the Coexistence section.

>IPv6 address but no PD came down.  I guess 6RD may be a good idea.

No PD came down is a very conscious decision by the SP to not allocate
any PD.  It's not like an admin in the SP domain fat-fingered a
provisioning system console.  Even if a SP mis-configuration caused no
PD to be sent to the client, did the SP also not send 6rd configuration
data in the DHCPv4 response?  The SP has can provide 6rd configuration
in the DHCPv4 responses.  Alternatively, the text says, 6rd is manually
configured. 

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 20 Oct 2011 22:16:37 +0900

> should the MTU be different than the default LAN link MTU and if so why?

Yes, if the upstream MTU is lower than the default LAN link MTU. Otherwise
you'll experience latency issues whenever you connect to a new host on the
Internet.

If possible, no. If it's not possible to do this and still meet the above,
then the above should take precedence.

if the MTU is set e.g. equal to the WAN MTU, what do you do in the case of a
> routed home? how do you propagate the MTU inside the network?

I'll pull an Ole and say that case is out of scope because 6204 only covers
the case of one CE router.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Oct 2011 08:41:06 -0500

Tassos,

Besides what you and Ole discussed, I have some comments below.

-----Original Message-----
From: Tassos Chatzithomaoglou [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 4:15 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

>       The activation of this behavior MAY be user-configurable. The LAN MTU SHOULD also 

First, if any text is added, the text has to be each LAN interface specific.  The home has a router with a wireless link.  The wireless link also sends out an RA and such a link is likely to have a different MTU than the wired LAN link in the home.  Now that transition tech has been added to the document, with tunnels there is the DF (Don't Fragment) bit.  See RFC 4449.  For now, I think the complexity of the routed home for MTU and tunnels is best handled manually.  With manual configuration, some extra knobs could be provided.  As you said a host can also set the MTU, and thus we may skip adding MTU related text to the LAN section.   Please also note that the rfc6204bis is merely adding two IP transition techs in 6rd and DS-Lite and IP Transition tech coexistence to RFC 6204 and thus other changes to the text form RFC6204 will only be made for editorial errors (such as replacing ICMP with ICMPv6) or if a Show Stopper problem is discovered in RFC 6204.  

Regards,

Hemant

Hemant

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Oct 2011 09:13:22 -0700

On Oct 20, 2011, at 6:16 AM, Lorenzo Colitti wrote:
> 
> Yes, if the upstream MTU is lower than the default LAN link MTU. Otherwise you'll experience latency issues whenever you connect to a new host on the Internet.

Because, as we all know, hosts on the LAN never ever communicate directly with one another at full media speeds using jumbo frames, as they all require every last one of their interactions to be mediated by the Cloud Buzzphrase Horsefeathers in the Sky™ or the terrorists win.

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

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 20 Oct 2011 18:42:07 +0200

On 2011-10-20 18:13 , james woodyatt wrote:
>> Yes, if the upstream MTU is lower than the default LAN link MTU.
>> Otherwise you'll experience latency issues whenever you connect to a
>> new host on the Internet.
> 
> Because, as we all know, hosts on the LAN never ever communicate
> directly with one another at full media speeds using jumbo frames, as
> they all require every last one of their interactions to be mediated by
> the Cloud Buzzphrase Horsefeathers in the Sky™ or the terrorists win.

<sarcasme>
You mean iCloud? :)
</sarcasme>

I almost commented a similar thing about local MTU needing to be the
same, till I re-read it again and till I rephrased that sentence in my
head as:

"The MTU on the upstream might be different (be that lower or higher),
if you don't set it properly, then you might have extra latency because
of packets will get dropped when it is wrong and packets will disappear"

As such, according to that, the following setup, which is very common is
totally acceptable:

LAN (4000) -> upstream-link (1480) -> internet (1280) -> remote host (1500)

Which is of course very logical and why we have Path MTU discovery.

Maybe the better comment is to definitely not filter ICMP Packet Too
Bigs and friends unless really needed.

Greets,
 Jeroen

---

From: Jared Mauch <[email-masked]>
Date: Thu, 20 Oct 2011 12:50:01 -0400

> Bigs and friends unless really needed.

This is a long war against the firewall culture that we are unlikely to win.  The less clued out there continue to set local security policies in a way that break and inhibit the proper use of technology.  While this may seem defeatist, we should certainly continue to educate these folks.

- Jared

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 20 Oct 2011 18:57:09 +0200

On 2011-10-20 18:50 , Jared Mauch wrote:
>> Maybe the better comment is to definitely not filter ICMP Packet
>> Too Bigs and friends unless really needed.
> 
> This is a long war against the firewall culture that we are unlikely
> to win.  The less clued out there continue to set local security
> policies in a way that break and inhibit the proper use of
> technology.  While this may seem defeatist, we should certainly
> continue to educate these folks.

I fully agree and there is little one can do against stupidity, but that
is why these and other drafts are coming out, the problem with that
though is getting people to actually read them, and say yourself, are
you really reading everything (well, on this list folks might actually ;).

Maybe it would be a good thing to ask the $endors to include a short but
very red "IPv6 Do's and Don't List" with every sale they make?

Then at least folks can't claim they didn't know about it.

Greets,
 Jeroen

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Oct 2011 10:34:33 -0700

On Oct 20, 2011, at 9:42 AM, Jeroen Massar wrote:
> 
> <sarcasme> You mean iCloud? :) </sarcasme>

I'm not going to stop you from taking it that way.  I actually have a whole series of piquant epithets, each of which I reserve for use when my intent is to be specific about which particular *brand* of Cloud Buzzphrase Horsefeathers in the Sky™ I wish to disparage.  Professional courtesy demands that I not use any of them here.

> Maybe the better comment is to definitely not filter ICMP Packet Too Bigs and friends unless really needed.

Lorenzo, I think, views the "latency issues" involved with Path MTU discovery as unacceptable.  I would suggest he should take that up with the 6MAN working group if he doesn't like it.  For our purposes, however, I suggest we lump it until 6MAN decides to reconsider.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 Oct 2011 10:48:21 -0700

> Of Jeroen Massar
> Sent: Thursday, October 20, 2011 9:42 AM
> To: james woodyatt
> Cc: IPv6 Operations; [email-masked]
> > the Cloud Buzzphrase Horsefeathers in the SkyT or the terrorists win.
> 
> <sarcasme>
> You mean iCloud? :)
> </sarcasme>
> 

Lost that war.  Let's try different approaches, such as PLPMTUD 
(packetization layer Path MTU Discovery) or a way to indicate 
different MTUs to the host:

Unfortunately, PLPMTUD with TCP (RFC4821) is unlikely to win hearts 
because it can be slow to notice an MTU problem, and can stall a 
connection while it is figuring that out.  PLPMTUD in SCTP, however,
is pretty neat stuff.

Indicating different MTUs to the host could go a long way towards 
solving the issue that James brought up -- we need a clean way to 
indicate to the host which routes or paths have small MTUs, so 
that communications within a network can use a large MTU.  If
it is known, a priori, that all communications to non-local 
addresses needs a small MTU (and can communicate that to the host)
we avoid Lorenzo's concern about slowing down Internet-
destined traffic that has to re-learn the path MTU again and
again.

-d

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Oct 2011 12:52:26 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jared Mauch
Sent: Thursday, October 20, 2011 12:50 PM
To: Jeroen Massar
Cc: IPv6 Operations; [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

>This is a long war against the firewall culture that we are unlikely to
win.  The less clued out there continue to set local security policies
in a way that >break and inhibit the proper use of technology.  While
this may seem defeatist, we should certainly continue to educate these
folks.

See RFC 4890, section 4.3.1.  

Hemant

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Oct 2011 11:01:48 -0700

On Oct 20, 2011, at 9:50 AM, Jared Mauch wrote:
> 
> This is a long war against the firewall culture that we are unlikely to win. 

Section 4.3.1 of RFC 4890 clearly describes Packet Too Big (Type 2) messages as Traffic That Must Not Be Dropped.  For good reason too.  Section 5.6.1 of I-D.ietf-6man-node-req-bis quotes RFC 2460 as follows: 

      It is strongly recommended that IPv6 nodes implement Path MTU
      Discovery [RFC1981], in order to discover and take advantage of
      path MTUs greater than 1280 octets.  However, a minimal IPv6
      implementation (e.g., in a boot ROM) may simply restrict itself to
      sending packets no larger than 1280 octets, and omit
      implementation of Path MTU Discovery.

RFC 4294 goes on to set this requirement:

   The rules in [RFC2460] and [RFC5722] MUST be followed for packet
   fragmentation and reassembly.

And I-D.ietf-6man-node-req-bis currently adds this pedagogical language:

   One operational issue with Path MTU discovery occurs when firewalls
   block ICMP Packet Too Big messages.  Path MTU discovery relies on
   such messages to determine what size messages can be successfully
   sent. [...]

Where RFC 2460 says this about Packet Too Big messages:

   If, after processing a Routing header of a received packet, an
   intermediate node determines that the packet is to be forwarded onto
   a link whose link MTU is less than the size of the packet, the node
   must discard the packet and send an ICMP Packet Too Big message to
   the packet's Source Address.

Note that RFC 2460 doesn't use the normative keyword style, so that "must" above is to be read as a "MUST" if you're looking for the cues that RFC 2119 keywords typically provide.

So, nodes are REQUIRED either to implement Path MTU discovery or constrain their MTU to 1280.  IPv6 forwarding planes are REQUIRED to send ICMP Packet Too Big messages when a packet cannot be forwarded with fragmentation.  Firewall implementations are given clear guidance that Packet Too Big messages are Traffic That MUST NOT Be Dropped.

If this is a conflict with "firewall culture" that IETF cannot reasonably be expected to win, then I have a hard time imagining why IETF should even bother meeting at all.  We should just let "firewall culture" write all the standards.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 20 Oct 2011 14:13:23 -0400

> See RFC 4890, section 4.3.1.  

Yeah, but try to make someone who says "i'm from IT/Security" i'm here to help read/know what a RFC is.

Lost cause in most cases.  These are the same folks who think that TCP/53 is just for zone transfers and will keep their head in the sand about dnssec/edns0 too.

- jared

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 Oct 2011 10:39:32 +1100

In message <[email-masked]>, Jared Mauch 
writes:
> Lost cause in most cases.  These are the same folks who think that TCP/53 is 
> just for zone transfers and will keep their head in the sand about dnssec/edn
> s0 too.

If you block PTB you get slow connections.
If you block DNS responses > 512 bytes you get slow DNS lookups.
If you block fragmented UDP you get slow DNS lookups.
If you block TCP/53 you get DNS lookup failures.

All of these are very noticable when they are occuring.

On the DNS side of things (the last 3) these are usually self
inflicted and can be self corrected.  Even Microsoft now accepts
TCP/53 to their servers though it took several years of complaints.

When I've encounted web sites that block PTB I've usually been able
to get the problem fixed.  For TCP/53 there is now a RFC that make
TCP/53 a MUST, overriding the stupid SHOULD on RFC 1123.

People do correct these sorts of faults.  I see this being done
regularly.  Yes, it is a slow process.

As for TCP/53, *all* of the root servers are currently sending out
incorrect referral for COM/NET etc as they are, incorrectly, dropping
glue records.  Only additional data is supposed to be dropped and
while glue is in the additional section it is *not* additional data.
This behaviour can cause referrals to fail.  GOV experienced such
failures a couple of months back and the solution was to upgrade the
servers to ones that set TC=1 when glue doesn't fit when the glue
matched the query.

Upgrading the root servers to alway set TC=1 when glue doesn't fit
will fix the TCP/53 isn't required myth.  Some of them already set
TC=1 when the glue matches the query and it doesn't fit.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 22 Oct 2011 13:48:05 +0900

On Fri, Oct 21, 2011 at 01:13, james woodyatt <[email-masked]> wrote:

> Because, as we all know, hosts on the LAN never ever communicate directly
> with one another at full media speeds using jumbo frames, as they all
> require every last one of their interactions to be mediated by the Cloud
> Buzzphrase Horsefeathers in the Sky™ or the terrorists win.
>

That's not the point. The point is how much traffic do you send / receive
from the Internet and how much from local hosts, and what is the performance
penalty of lowering the MTU from (say) 1500 to 1480 for either. Do you
really use jumbo frames? All my devices have ethernet MTUs of 1500.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 22 Oct 2011 13:50:58 +0900

On Fri, Oct 21, 2011 at 02:48, Dan Wing <[email-masked]> wrote:

> that communications within a network can use a large MTU.

Agreed. We should to make MTU a per-path, not per-link, attribute. After
all, the host already knows from layer 2 hints what the local link MTU is.
The good news is that we wouldn't need to change any packet formats to do
that, we could simply make it so that the MTU in the RA would apply to the
default route.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 22 Oct 2011 13:52:06 +0900

On Fri, Oct 21, 2011 at 03:13, Jared Mauch <[email-masked]> wrote:

> Lost cause in most cases.  These are the same folks who think that TCP/53
> is just for zone transfers and will keep their head in the sand about
> dnssec/edns0 too.

The good news is that when these guys take "deny icmp any any" and translate
it into IPv6, they'll notice that nothing works at all, because you just
killed local neighbour discovery. So they will be forced to think about that
problem one way or another.

---

From: james woodyatt <[email-masked]>
Date: Fri, 21 Oct 2011 23:47:55 -0700

On Oct 21, 2011, at 21:48 , Lorenzo Colitti wrote:
> 
> Do you really use jumbo frames?

Behold the horror: System Preferences => Network => Ethernet => Advanced... => Hardware.

Consider for a moment how much hatred and loathing you must know that I feel for this entire sheet in the Network system preferences pane.  I so very much wish that nobody anywhere used Jumbo or "custom" MTU sizes.  It would make my day job so much simpler than it is today.  Alas, I assure you: people use this. In fact, there are probably more people using this than people using 6to4.

---

From: Washam Fan <[email-masked]>
Date: Sat, 22 Oct 2011 18:13:54 +0800

Hi Lorenzo,

>From my experience, MTU in the RA is the MTU of the link to which the
advertising interface of the router attaches. I.e., the PMTU for the
host-to-host communication within the link. For host-to-host
communication beyond the link, either PMTU mechanism should be
employed or 1280 is used.

Thanks,
washam