Subject: Review of 'draft-xu-v6ops-hybrid-framework-00.txt'

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 2 Sep 2009 14:20:42 -0700

Below is my review of 'draft-xu-v6ops-hybrid-framework-00.txt':

Fred
[email-masked]

---

1) Abstract, the phrase "as many as possible" seems at
odds with trusting the ISP to make informed choices.
Suggest changing this to: "ISP networks may need to
support multiple IPv6 connectivity solutions".

2) Section 1, paragraph 3, the phrase: "including the support
of configured IPv6-over-IPv4 tunnels" should be shortened to
"including the support of IPv6-over-IPv4 tunnels".

3) Section 1, paragraph 3, the phrase: "cannot be sufficient
once IPv4 addresses have run out, because it" is not correct,
because dual stack can still be used in environments that
use IPv4 privacy addresses, which can exist even after the
global IPv4 address run-out. Suggest shortening sentence to:

  "However, the dual stack approach does not allow IPv6-only
   hosts to communicate with IPv4-only hosts."

which is true under any circumstances.

4) Section 1, paragraph beginning with "Each technique...",
add VET to the "For example" list, i.e., as:

  "For example, VET (Virtual Enterprise Traversal [VET]),
   6RD (IPv6 Rapid Deployment [6RD]), Port Range ..."

5) Section 1, paragraph beginning with "Up to now",
change: "ISP networks need to support as many IPv6
connectivity solutions as is operationally reasonable"
to" "ISP networks may need to support multiple IPv6
connectivity solutions".

6) Section 2, third paragraph, the trailing sentence: "Note
that IPv6 autoconfiguration is not powerful enough for this
purpose." does not seem to add any value and may instead
serve only to confuse. Can this sentence be dropped?

7) Section 2, the paragraph beginning: "The hybrid ISP
framework", change first sentence to: "The hybrid ISP
framework may need to support multiple IPv6 connectivity
solutions."

8) Section 3, second paragraph beginning: "In order to
find NATs and traverse them,", this text seems to imply
that *all* applications need to be made NAT-aware when
in fact many/most applications are oblivious to NATs.
Is there a certain class of applications this text is
meaning to refer to? If so, the assumptions must be
stated.

9) Section 4.2 should also cite IPv6 Prefix Options for
DHCPv6 [RFC3633].

10) Section 4.3, DNS SRV is not the only method used for
service resolution. Remove the phrase: "using DNS SRV
[2782]".

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Sep 2009 10:32:40 -0700

Hi Sheng,

> -----Original Message-----
> From: Sheng Jiang [mailto:[email-masked]]
> Sent: Monday, September 07, 2009 10:14 AM
> To: Templin, Fred L; 'v6ops'
> Cc: [email-masked]; 'Brian E Carpenter'
> Subject: RE: Review of 'draft-xu-v6ops-hybrid-framework-00.txt'
> 
> Hi, Templin,
> 
> Thanks so much for your reviewing and comments.
> 
> All of your comments are accepted and will be reflected in the next
version,
> except for the below one. Can I ask you a question here: overall, do
you
> think this draft is suitable for v6ops charter and mature enough to be
> adopted as wg file?
> 
> I guess, this refer is to these applications that want to traverse
NATs. If
> you have any specific text to suggest, we may adopt it in the next
version.

I guess when I think of NAT discovery and traversal, I
think of NAT-specific end system services like STUN, TURN,
ICE, TEREDO, etc. and not about "ordinary" IPv4 applications
like ftp, web browsing, etc. Here is a proposed rewrite that
I think could accommodate the concern:

  "In order to find NATs and traverse them, end system services
   have to understand network protocols deeply, invoke or interact
   with network protocols directly and analyse network behaviours
   by themselves, since the protocol stack on the end system is
   not aware of NATs.

Fred

> Many thanks and best regards,
> 
> Sheng
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of Templin, Fred L
> > Sent: Thursday, September 03, 2009 5:21 AM
> > To: v6ops
> > Cc: [email-masked]; JiangSheng 66104; Brian E Carpenter
> > Subject: Review of 'draft-xu-v6ops-hybrid-framework-00.txt'
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Sep 2009 14:08:52 +1200

>    by themselves, since the protocol stack on the end system is

That seems correct; VoIP and P2P for example have to be aware
that there may be NATs in the path. In the GRO work
(draft-carpenter-behave-referral-object), we assume that
applications need to be aware of non-transparency in general.

I fear that we're heading towards a world in which applications
without this awareness will stop working.

    Brian