Subject: Re: New Version Notification for draft-jiang-v6ops-incremental-cgn

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Jun 2009 08:12:37 +0100

Janos,

(Delayed reply, sorry)

On 2009-05-20 15:25, Mohacsi Janos wrote:
> 
> 
> Janos Mohacsi
> Network Engineer, Research Associate, Head of Network Planning and Projects
> NIIF/HUNGARNET, HUNGARY
> Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882
> 
> On Wed, 20 May 2009, JiangSheng 66104 wrote:
> 
>>> A document such as this is very helpful and I thank the authors.
>>> One concern I have about this kind of model is the widespread
>>> ICMP filtering in IPv4 networks. I see many ISPs that filter ICMPv6
>>> just as they do with IPv4 and has been causing problmes. This
>>> is especially important in a tunnel based solution such as this.
>>
>> Hi, Seiichi, thanks for your reply. I understand your concern. Yes,
>> ICMP fliter is a problem. We will take this in count later.
> 
> They should have a look at this draft:
> 
> http://tools.ietf.org/html/rfc4890
> 

Do you think the draft needs to do any more than recommending to follow
the recommendations in 4890? It seems as if that should be sufficient.

Any other points in this draft that we should fix before the cutoff
date?

    Brian

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 4 Jun 2009 17:02:50 +0200 (CEST)

> the recommendations in 4890? It seems as if that should be sufficient.

This should be enough.
 	Best Regards,
 			Janos

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 4 Jun 2009 08:44:16 -0700

> > the recommendations in 4890? It seems as if that should be
sufficient.

Regarding the 4890, there is advice in that document that I
would like to understand better. In Appendix A.2, it says:

   "If a network chooses to generate packets that are no larger than the
   Guaranteed Minimum MTU (1280 octets) and the site's links to the
   wider Internet have corresponding MTUs, Packet Too Big messages
   should not be expected at the firewall and could be dropped if they
   arrive."

But, that would seem to be in conflict with the text of
Section 5 of RFC2460, where the reader is informed that
the network can return PTB messages reporting MTU values
smaller than 1280 if a protocol translator is in the path.
The host should then react to these PTBs by inserting a
fragment header with (MF=0; Offset=0) in subsequent packets.
With the (RFC4890, Appendix A.2) text however, this behavior
is suppressed.

Where did the RFC4890 text come from? And, why is it there?

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Jun 2009 07:04:04 -0700

I guess I have to ask again. Can the RFC4890 authors please
comment on the RFC4890, Section A.2 text questions asked in
my previous message (below)?

Fred

> -----Original Message-----
> From: Templin, Fred L
> Sent: Thursday, June 04, 2009 8:44 AM
> To: Mohacsi Janos; Brian E Carpenter
> Cc: JiangSheng 66104; Seiichi Kawamura; Gert Doering; Fleischman,
Eric; Re'mi Despre's;
> [email-masked]; [email-masked]; Russert, Steven W
> Subject: RE: New Version Notification for
draft-jiang-v6ops-incremental-cgn

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 9 Jun 2009 10:12:22 +0200 (CEST)

Dear Fred,
 	I try to figure out from my notes what was the reason of the text. 
Best Regards,

Janos Mohacsi

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jun 2009 08:22:10 +0100

Any more input on this draft before we update it? We plan to
ask for WG adoption in Stockholm.

  Brian, Sheng and Dayong

---

From: Fred Baker <[email-masked]>
Date: Thu, 11 Jun 2009 04:26:21 -0700

> ask for WG adoption in Stockholm.

Well, yes. My understanding is that the topic of CGNs is moving to  
behave, and so should be submitted to behave. You can verify with the  
behave chairs.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jun 2009 07:35:44 -0700

Fred,
 
> behave, and so should be submitted to behave. You can verify with the

The subject matter of this document seems more concerned
with what IPv6 operational functions could be placed on a
platform that might also support a CGN function, rather
than the behavioral aspects of CGN itself. If the bulk
of the material is about IPv6 transitions, wouldn't that
qualify the document to remain targeted to this group?

Fred

---

From: Fred Baker <[email-masked]>
Date: Thu, 11 Jun 2009 08:22:05 -0700

well, remembering that we are actually NOT CHARTERED TO DISCUSS  
TRANSITION ALGORITHMS, no. What I have been told is that matters  
relating to network address translation and network protocol  
translation have been moved to the working group chartered to discuss  
that.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Jun 2009 08:25:14 -0700

Fred,

> From: Fred Baker [mailto:[email-masked]]
> Sent: Thursday, June 11, 2009 8:22 AM
> To: Templin, Fred L
> Cc: Brian E Carpenter; IPv6 Operations; Behave Chairs
> Subject: Re: draft-jiang-v6ops-incremental-cgn
> 

Sorry - I used a wrong word. I meant to say "IPv6 operations";
not "IPv6 ****sitions".

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Jun 2009 07:57:41 +0100

Fred and Fred,

The draft explicitly does not propose any new mechanisms;
it describes operational scenarios using existing mechanisms
or proposed future mechanisms. I don't see a better fit than
the v6ops charter at the moment.

    Brian