Subject: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt

From: Pekka Savola <[email-masked]>
Date: Mon, 3 Nov 2003 15:03:20 +0200 (EET)

Hi all,

This is a WG Last Call for comments on sending
draft-ietf-v6ops-mech-v2-01.txt, "Basic Transition Mechanisms for IPv6
Hosts and Routers", to the IESG for consideration as Proposed Standard:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-01.txt

(We're hoping to recycle to Draft Standard soon afterwards.)

Please review these documents carefully, and send your feedback to the
list.  Please also indicate whether or not you believe that this document
is ready to go to the IESG.  Silence does NOT indicate consent.  Unless
sufficient support is demonstrated on the list, the documents will not be
sent to the IESG.

The last call will end in about 3 weeks, on 25th November.

Pekka, Jonne & Bob

---

From: Pekka Savola <[email-masked]>
Date: Fri, 7 Nov 2003 17:32:53 +0200 (EET)

Hi,

ADDITONAL NOTE: due to the WG feedback, we'll be investigating whether to
go to DS directly.

If you have preferences about this, please indicate that when sending
feedback on the draft in WG LC.

In any case, if we can't get to DS immediately, we'll do it soon 
afterwards, so a lot review for the document would be appreciated!

Pekka
 writing as co-chair

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 8 Nov 2003 07:02:22 +0900 (JST)

> > Hosts and Routers", to the IESG for consideration as Proposed Standard:

	suggestion in section 3.7 (quoted below) is unneecessary, or seems
	too strong.  could we remove it, or make it MAY instead of SHOULD
	at least?

	reasons:
	- coupling link-local address with tunnel endpoint IPv4 address makes
	  it harder to switch tunnel endpoint IPv4 address - reconfiguration
	  of IPv6 link-local address (usually used for nexthop) is needed.
	  therefore i prefer them to be separate.  it is from my long
	  operational experience.
	- RFC2472 section 4.1 has better way to generate interface ID.
	- SHOULD is too strong as the use of different selection algorithm
	  of link-local address here does not impose any interoperability issue.

	btw, RFC1933 did not have such requirement (SHOULD).  RFC2893
	introduced this.  i did voiced my concern but was not integrated into
	RFC2893.

itojun

>   The Interface Identifier [RFC2373] for such an Interface SHOULD be
>   the 32-bit IPv4 address of that interface, with the bytes in the same
>   order in which they would appear in the header of an IPv4 packet,
>   padded at the left with zeros to a total of 64 bits.  Note that the
>   "Universal/Local" bit is zero, indicating that the Interface
>   Identifier is not globally unique.  When the host has more than one
>   IPv4 address in use on the physical interface concerned, an
>   administrative choice of one of these IPv4 addresses is made when
>   forming the link-local address.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Nov 2003 19:40:32 +0200 (EET)

> 	too strong.  could we remove it, or make it MAY instead of SHOULD

FWIW¸ I don't have a strong opinion either way.  RFC2472 can't be listed
as normative reference, and the algorithm is too long to describe.  MAY
could be OK here, with a caveat that this is indeed for bidirectional
tunneling only.

(For example, some mechanisms may want to re-use the encoding to embed the 
tunnel address to the low-end  address.  With bi-dir configured tunneling, 
this should not really be an issue.)
 
> 	  therefore i prefer them to be separate.  it is from my long

Inheriting it from a physical device has its own problems, e.g. if the
hardware fails on the tunnel peer.  A setting independent of MAC address
has some uses.

Note: the document should be clearer that configured tunnels are typically 
point-to-point, and then you typically don't even need the link-local 
addresses, so this becomes practically rather irrelevant..

[...]
> 	  of link-local address here does not impose any interoperability issue.

True, I don't really see that w/ configured tunneling how the address is 
configured really matters at all..

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 10 Nov 2003 02:45:25 +0900 (JST)

> addresses, so this becomes practically rather irrelevant..

	RFC2373/3513:
	    All interfaces are required to have at least one link-local unicast
	    address.

	i guess what you are trying to mean is "don't even need to USE the
	link-local address of the peer, or the node itself".

itojun

---

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Nov 2003 19:51:32 +0200 (EET)

> 	link-local address of the peer, or the node itself".

Yep, of course.  The address is needed, but there's no use sweating too
much what it is if it shouldn't need to be used anyway (by users at
least).. :-)

Note: another thing to say is that if you have N v4 addresses, you 
don't have to generate a N link-local addresses.. should be obvious though 
:-)

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Mon, 10 Nov 2003 02:53:49 +0900 (JST)

> much what it is if it shouldn't need to be used anyway (by users at

	for implementers it matters a lot :-)

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Nov 2003 16:03:48 +0100 (CET)

> addresses, so this becomes practically rather irrelevant..

There are some cases when link-locals would be required. For instance,
for a host-router tunnel it might make sense for the router to send router
advertisements and those must be sourced with link-local addresses.

For a router-router tunnel I think the link-locals can be omitted, unless they
are used as next-hops across the tunnel.

Given this we need to specify one way to pick link-local addresses by default
for configured tunnels so that the two ends don't pick the same address.
Either using the IPv4 address (with "local") or an EUI-64 derived address
(with "local" not set) would work.

   Erik

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 11 Nov 2003 00:46:35 +0900

>>>>> On Mon, 10 Nov 2003 16:03:48 +0100 (CET), 
>>>>> Erik Nordmark <[email-masked]> said:

> are used as next-hops across the tunnel.

I think link-locals are often "used", particularly when we run an IGP
(RIPng, OSPFv3, or ISIS) across the tunnel.  (But this is so obvious
that I'm not sure if this discussion really missed this point in the
first place...)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Tim Chown <[email-masked]>
Date: Wed, 12 Nov 2003 19:28:54 +0000

A handful more comments on draft-ietf-v6ops-mech-v2-01.txt, which
may be duplicates...

1. Why is IPv4 compatible addressing defined in the first section,
   if it is deprecated?  

2. IPv4 compatibles are mentioned in 3.6 - this should be removed
   (aren't general multicast source addresses dropped anyway?)

3. Section 2 starts "the most straightforward way", though this
   is the only way in this document? 

4. In 2.2 should we mention that that app may or may not be v6 aware or
   capable?  The shin-application-transition draft could be pointed to,
   although it is not a WG item ist looks very good work.

5. In 2.3 there are 2 references to 6bone.  Should probably use something else
   given 6bone is deprecated.

6. In section 3, or in the introduction,  some mention should probably be made 
   as to why automatic tunneling (6to4, RFC3056) is not inlcuded in the
   basic mechanisms (it postdates 2893 but is omitted).

Tim

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Nov 2003 17:27:36 +0100 (CET)

Thnaks for the comments.

> 1. Why is IPv4 compatible addressing defined in the first section,

To say that it is deprecated. But perhaps we should ask to do this
in the ipv6 addressing architecture update.

>    (aren't general multicast source addresses dropped anyway?)

I think dropping compatibles make sense because they shouldn't be used
any more.

>    is the only way in this document? 

Yes. Is that confusing? Suggestions for different way to start things off?

>    although it is not a WG item ist looks very good work.

Already received a comment about not adding AAAAs until the apps/services
on the node support IPv6. 
Would that address your comment or should I add something slightly different?

>    given 6bone is deprecated.

oops. I'll say something vague as "connected to the Internet using IPv6"
unless there is a better suggestion.

>    basic mechanisms (it postdates 2893 but is omitted).

Explicitly listing others is a potential slippery slope; we can argue for
a long time which ones to explicitly list as not being included :-(
Isn't the current text sufficient? It says:
   Other transition mechanisms, including other tunneling mechanisms,
   are outside the scope of this document.

  Erik

---

From: Tim Chown <[email-masked]>
Date: Fri, 14 Nov 2003 16:55:23 +0000

> in the ipv6 addressing architecture update.

OK, but that could simply be in the changes section, not in the definitions
section, as if the 3.6 reference is removed IPv4 compatibles are then only
mentioned in the changes section.   having them in the defs kind of suggests
they are valid.
 
> Yes. Is that confusing? Suggestions for different way to start things off?

I guess if we said "the recommended way" that might get some objection.
I think part of the "problem" is that the draft doesn't set context anywhere,
e.g. it doesn't state why automatic methods such as 6to4 are not cited,
or why NAT-PT isn't mentioned as a "less straightforward" way of having
compatibility.   Perhaps "The only way for IPv6 nodes to remain fully
compatible with IPv4-only nodes is by...", and then make some comment that
without that translation is needed? (a quick grep shows not one instance
of the word "translation" so again I think some text near the start setting
the scope here would really help).

In short, the first line of the abstract would suggest that translation
methods should be cited, but in fact the document really focuses on tunnel
methods that IPv6 hosts/routers can use to communicate over IPv4 networks.
Maybe this focus changed over the three iterationbs of this RFC?

> Would that address your comment or should I add something slightly different?

I think one thing shin-application-transition captures well is the issue
of v4/v6 enabled on the host and v4/v6 application capability (and thus the
potential usage of mapped addresses for example).   I guess 2.2 talks
about the protocol used on the wire, so the presentation to the app as
a mapped address may be out of scope here.
 
>    are outside the scope of this document.

See above - I think the first sentence of the abstract suggests otherwise,
and this sentence I think is used in the intro text at least too.  If you
just want to make one change, then a statement in the asbtract and after
paragraph 1 of the intro to say that translation techniques are not in
scope would help, I think.

Sorry if this seems a little pedantic :)

Tim

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Nov 2003 16:01:42 +0100 (CET)

> mentioned in the changes section.   having them in the defs kind of suggests

I misspoke - strictly speaking this document doesn't deprecate them - it
just no longer uses them. The doc contains this in the changes section:
	Removed automatic tunneling and use of IPv4-compatible addresses.

We could make this document deprecate them, but it would make
more sense to perform such an action in draft-ietf-ipv6-addr-arch-v4-00.txt

> e.g. it doesn't state why automatic methods such as 6to4 are not cited, or
> why NAT-PT isn't mentioned as a "less straightforward" way of having
> without that translation is needed? (a quick grep shows not one instance of
> the word "translation" so again I think some text near the start setting the
> scope here would really help).

I agree that this document describes how implementors can build car
engines; it does not teach people to drive cars.
Hence providing an overview of all possible transition or even tunneling
mechanisms is out of scope. We can have other RFCs do that.

"The only way ... fully ..." is an even more questionable opinion than
"the most straightforward way ..." - a http proxy can be argued to
be fully compatible from the perspective of http applications.

So I'm still not seeing how you would like to edit the document on the table
to make it more clear; you seem to be mixing this clarifying task with
wanting a different, more overview'ish, document on the table.

> Maybe this focus changed over the three iterationbs of this RFC?

I think the abstract contains marketing - maybe time to get rid of that.

> scope would help, I think.

"first"? I assume you mean that 3rd sentence in the abstract which says:
	They are designed to allow IPv6 nodes to
	maintain complete compatibility with IPv4, which should greatly
	simplify the deployment of IPv6 in the Internet, and facilitate the
	eventual transition of the entire Internet to IPv6.

I suggest just dropping that sentence.

It is easier to say that dual stack and configured tunnels are in scope than
trying to first define what "translation" is for the sole purpose of
saying that it is out of scope. FWIW I think the definitional problem
is a hard one; is a http proxy (on a dual stack node) a "translation" or not.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Nov 2003 16:06:17 +0100 (CET)

Suggested updated abstract which should make the scope more clear:

This document specifies IPv4 compatibility mechanisms that can be
implemented by IPv6 hosts and routers.
The document specifies the two mechanisms "dual stack" and configured
tunneling.  Dual stack implies providing complete implementations of both 
versions of the Internet Protocol (IPv4 and IPv6) and configured tunneling
provides a mean to carry IPv6 packets over unmodified IPv4
routing infrastructures.

  Erik

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 Nov 2003 15:19:06 +0000

> more sense to perform such an action in draft-ietf-ipv6-addr-arch-v4-00.txt

OK, I misunderstood what was happening; I thought compatibles were being 
deprecated.

> I think the abstract contains marketing - maybe time to get rid of that.

OK.

It looks like a lot of text is carried forward in the early pages from the
first version which I guess was written a few years ago now.

> I suggest just dropping that sentence.

OK.
 
> is a hard one; is a http proxy (on a dual stack node) a "translation" or not.

Fair point.   If we say the best way for two hosts to interoperate
is to both support the same v4 or v6 stack, it does beg the question as
to what the alternative is, if its not even hinted at.   But since noone
else has commented I suggest you ignore that concern :)

Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 Nov 2003 15:21:57 +0000

> provides a mean to carry IPv6 packets over unmodified IPv4

Much better.   Removes the "best way..." concern nicely.

We should progress v4 compatible deprecation if this isn't in here.

Thanks,
Tim

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Nov 2003 21:55:14 -0800 (PST)

> We should progress v4 compatible deprecation if this isn't in here.

Need to send a comment to ipv6 WG on addr-arch-v4 to get them deprecated.
Do you want to do that?

  Erik