Subject: (ngtrans) working group last call for MECH-05 - closes 24 April 2000

From: Bob Fink <[email-masked]>
Date: Mon, 10 Apr 2000 12:29:12 -0700

NGtrans Folk,

The following MECH-05 draft has just been published and contains changes 
from accumulated comments. The author and the chairs felt it appropriate to 
redo the last call.

Thus there will be a two-week ngtrans working group last call.

Comments to the list by 24 April 2000.

Thanks,

Bob

 >----------------Begin Forwarded Message----------------<

Date: Mon, 10 Apr 2000 07:34:34 -0400
From: [email-masked]
Subject: (ngtrans) I-D ACTION:draft-ietf-ngtrans-mech-05.txt
To: IETF-Announce@, @
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Generation Transition Working Group of
the IETF.

	Title		: Transition Mechanisms for IPv6 Hosts and Routers
	Author(s)	: R. Gilligan, E. Nordmark
	Filename	: draft-ietf-ngtrans-mech-05.txt
	Pages		: 29
	Date		: 06-Apr-00
	
This document specifies IPv4 compatibility mechanisms that can be
implemented by IPv6 hosts and routers.  These mechanisms include
providing complete implementations of both versions of the Internet
Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4
routing infrastructures.  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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ngtrans-mech-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ngtrans-mech-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
 >----------------End Forwarded Message----------------<

---

From: [email-masked]
Date: Wed, 12 Apr 2000 03:40:36 +0900

>from accumulated comments. The author and the chairs felt it appropriate to 

	I got two comments on it.  Thank you for clarifying ingress filtering
	rules.

itojun

section 3.6 says this:

>   After the decapsulation the node SHOULD silently discard a packet
>   with an invalid IPv6 source address.  This includes IPv6 multicast
>   addresses, the unspecified address, and the loopback address but also
>   IPv4-mapped IPv6 source addresses where the IPv4 part of the address
    ~~~~~~~~~~~~~~~~~~~~~~~
>   is an (IPv4) multicast address, broadcast address, 0.0.0.0, or
>   127.0.0.1.  In general it SHOULD apply the rules for martian
>   filtering in [18] and ingress filtering [13] on the IPv4-compatible
>   source address.

The underlined part is a typo.  It should be "IPv4-compatible IPv6 source".
In certain cases it is more secure to drop packets with IPv4-mapped IPv6
address as well, though.

mech-05 page 19 suggests to use fe80:0:0:0:0:0:ipv4addr as link-local address
for tunnel interfaces.  It was not in RFC1933.

>   The Interface Identifier [14] of an IPv4 interface is 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.
>   The IPv6 Link-local address [14] for an IPv4 virtual interface is
>   formed by appending the Interface Identifier, as defined above, to
>   the prefix FE80::/64.
>
>   +-------+-------+-------+-------+-------+-------+------+------+
>   |  FE      80      00      00      00      00      00     00  |
>   +-------+-------+-------+-------+-------+-------+------+------+
>   |  00      00   |  00   |  00   |   IPv4 Address              |
>   +-------+-------+-------+-------+-------+-------+------+------+

The wording is not very clear about if it is a requirement or one example.
This looks for me to be just an example, since there's no real requirement
for putting IPv4 address into the link-local address, since:
- we do not use lowermost 4 bytes for special use
- the story does not change even if we use random number with u/l bit set to 0
- we will know about duplication by DAD
I agree IPv4 address is a good pick for avoiding duplication, however,
it becomes tricky whenever IPv4 address of the node changes (renumbered).
I'd suggest to make it clearer that it is only an example.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Apr 2000 14:48:12 -0700 (PDT)

> In certain cases it is more secure to drop packets with IPv4-mapped IPv6

Oops - I'll fix.

> for tunnel interfaces.  It was not in RFC1933.

Yes, but it was in mech-04.

> - the story does not change even if we use random number with u/l bit set to
> 0 - we will know about duplication by DAD

I'll stick in a "MUST" to get:
The Interface Identifier [14] for such an Interface MUST be the 32-bit 
IPv4 address of that interface, with the bytes in the same order in 
...

(I think I got the text from 6over4 originally.)

   Erik

---

From: [email-masked]
Date: Wed, 12 Apr 2000 14:53:28 +0900

>(I think I got the text from 6over4 originally.)

	hmm, MUST looks too strong to me, as the choice for interface
	identifier does not raise any interop issue.  also it would prevent us
	from becoming IPv4 renumber independent.  how about SHOULD?

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Apr 2000 11:23:05 -0700 (PDT)

> 	from becoming IPv4 renumber independent.  how about SHOULD?

SHOULD it is.
I'll submit -06 with a SHOULD (and the typo you found corrected).

  Erik

---

From: [email-masked]
Date: Mon, 17 Apr 2000 03:42:47 +0900

>I'll submit -06 with a SHOULD (and the typo you found corrected).

	thanks,

	for future documentations...
	it seems that RFC2472 4.1 is very well-written for interface identifier
	selection for pseudo interfaces (and tunnel interface fits with the
	section very well).  it may be nice if we make a separate document
	from the section and refer it.

itojun