Subject: Documents Ready for DS

From: Margaret Wasserman <[email-masked]>
Date: Wed, 24 Apr 2002 16:26:39 -0400

The chairs have identified several IPv6 documents that should be ready to move from Proposed
Standard to Draft Standard.  

This process is already underway for:

RFC2373: IPv6 Addressing Architecture (as updated by draft-ietf-ipngwg-addr-arch-v3-07.txt)

We would also like to start the process for the following documents:

RFC1886: DNS Extensions for IPv6 
RFC2464: IPv6 over Ethernet 
RFC2467: IPv6 over FDDI 
RFC2470: IPv6 over Token Ring 
RFC2473: Generic Packet Tunneling in IPv6 Specification
RFC2710: MLD for IPv6
RFC2526: Reserved IPv6 Subnet Anycast Addr

These documents have all been stable for over 2 years, and there should be multiple implementations
of each of them.

Does anyone know of any reason why any of these documents should not be advanced?  Any
updates in progress?  Any serious technical flaws that should be corrected before they are 
advanced?

If there are no objections from the list, we will begin the process of gathering implementation
reports to advance these documents.

Thanks,
Margaret

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 24 Apr 2002 23:35:38 +0300 (EEST)

> RFC2470: IPv6 over Token Ring 
[...]
> These documents have all been stable for over 2 years, and there should
> be multiple implementations of each of them.

Actually, I'm not sure if there are all that many implementations of 
these...

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Alain Durand <[email-masked]>
Date: Wed, 24 Apr 2002 14:01:24 -0700

> RFC1886: DNS Extensions for IPv6

It was my understanding after London IETF that this document belonged to
the DNSext wg.

Randy, Olafur?

    - Alain.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 24 Apr 2002 17:06:47 -0400

Hi All,

>It was my understanding after London IETF that this document belonged to

Just to be clear -- this is the AAAA document, not the A6 document.

If it now belongs to DNSext, do they have plans to advance it?  We are trying to
get all of the basic IPv6 specs advanced to DS as soon as possible, and this 
would clearly qualify.

Margaret

---

From: Alain Durand <[email-masked]>
Date: Wed, 24 Apr 2002 14:26:55 -0700

> Just to be clear -- this is the AAAA document, not the A6 document.

You're correct.

> get all of the basic IPv6 specs advanced to DS as soon as possible, and this

There is a group of people working on an interoperability report.

    - Alain.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 24 Apr 2002 17:48:15 -0400

>There is a group of people working on an interoperability report.

Great!  If we can get confirmation that this document belongs to DNSext,
I will remove it from the IPv6 list.

Thanks,
Margaret

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 24 Apr 2002 18:28:10 -0400 (EDT)

Yes, DNSext will advance this this document.
If there is ever any other address record document for IPng (A6 or
something else).

	Olafur

---

From: [email-masked]
Date: Thu, 25 Apr 2002 08:31:45 +0900

>RFC2473: Generic Packet Tunneling in IPv6 Specification

	i have a couple of comments on this document.  i'd like to see these
	addressed before this document proceeding further.

itojun

- tunnel encapsulation option (4.1.1, 5.1) does not seem to be widely
  implemented/operated.  if my observation is correct, i'd suggest droppping it.
- TOS/traffic class field processing rule is not friendly with ECN
  (6.4).  i'd propose to add reference to RFC3168 section 9 and follow
  them.
- icmp message relay/translation (8) does not seem to be widely
  implemented/operated, and could even be abused (open relay of packet - it is
  not mentioned in security issues section).  if my observation is correct,
  i'd suggest removing the rule.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 25 Apr 2002 08:32:44 +0900

>RFC1886: DNS Extensions for IPv6 

	this one needs IP6.INT -> IP6.ARPA change, at least.

itojun

---

From: Bill Manning <[email-masked]>
Date: Wed, 24 Apr 2002 17:25:41 -0700 (PDT)

one does not change RFCs, one issues replacements.

% >RFC1886: DNS Extensions for IPv6 
% 
% 	this one needs IP6.INT -> IP6.ARPA change, at least.
% 
% itojun
% --------------------------------------------------------------------
% IETF IPng Working Group Mailing List
% IPng Home Page:                      http://playground.sun.com/ipng
% FTP archive:                      ftp://playground.sun.com/pub/ipng
% Direct all administrative requests to [email-masked]
% --------------------------------------------------------------------
% 

-- 
--bill

---

From: [email-masked]
Date: Thu, 25 Apr 2002 09:31:54 +0900

> one does not change RFCs, one issues replacements.

	i understand that, thanks for clarification.

	(sorry for continuing this on ipngwg, not dnsext0
	don't we need suggestions in the document, regarding to transition
	from ip6.int to ip6.arpa?  for example, i think client resolvers should
	do

		try blah.ip6.arpa;
		if (not found)
			try blah.ip6.int;

	as there are name tree populated on ip6.int.

itojun

---

From: Bill Manning <[email-masked]>
Date: Wed, 24 Apr 2002 17:59:44 -0700 (PDT)

% >% >RFC1886: DNS Extensions for IPv6 
% >% 	this one needs IP6.INT -> IP6.ARPA change, at least.
% > one does not change RFCs, one issues replacements.
% 
% 	i understand that, thanks for clarification.
% 
% 	(sorry for continuing this on ipngwg, not dnsext0
% 	don't we need suggestions in the document, regarding to transition
% 	from ip6.int to ip6.arpa?  for example, i think client resolvers should
% 	do
% 
% 		try blah.ip6.arpa;
% 		if (not found)
% 			try blah.ip6.int;
% 
% 	as there are name tree populated on ip6.int.
% 
% itojun

	While there seems to be progress on the 3ffe:: front
	(wrt migrating it to ip6.arpa) we will be forever 
	stuck on any 2002:: or other user maintained mappings
	due to RFC 3052 (I think thats the one that specifies
	.arpa as the swank new anchor point) so for the
	forseeable future, there will always be parts of the v6
	tree in ip6.int that will never be reflected in ip6.arpa.
	
	ip6.arpa will remain a subset of ip6.int.

	one might better optimize the loop as:

		try blah.ip6.int;
		if (not found)
			try blah.ip6.arpa;

---

From: David Terrell <[email-masked]>
Date: Wed, 24 Apr 2002 18:28:18 -0700

> 	tree in ip6.int that will never be reflected in ip6.arpa.

While I can understand their position (or perhaps, "taking a position
that does not accept 2.0.0.2.ip6.arpa", since I don't know their
motivation) since there is no standard yet coming out of ngtrans
wrt that zone, it is frustrating that several years after the
initiative was made to move ip6.int to .arpa that there are still
large obvious barriers to doing so, and more and more IPv6 code 
is going to have to deal with this legacy arpa/int mess.  Getting
it done and cleaning up later should be a reasonably high prority.

No political opinion on the worth or lack thereof of ICANN is 
intended or implied....

-- 
David Terrell           | "The Court understands fully why licensing has many 
Nebcorp Prime Minister  | advantages for software publishers. However, this 
[email-masked]            | preference does not alter the Court's analysis that 
http://wwn.nebcorp.com/ | the substance of the transaction at issue here is a 
  sale and not a license." - Judge Dean Pregerson, Softman v Adobe.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Apr 2002 11:33:31 +0200

> RFC2470: IPv6 over Token Ring

I'm told there are bugs in the document, and no known implementations.
So this is a candidate for further sleep, or maybe Historic.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 25 Apr 2002 07:23:30 -0400

> RFC1886: DNS Extensions for IPv6 

has ip6.int as opposed to arpa.

randy

---

From: Jason Maas <[email-masked]>
Date: Thu, 25 Apr 2002 10:53:41 -0400 (EDT)

>So this is a candidate for further sleep, or maybe Historic.

I don't know much about token-ring or about bugs in the document, but
Linux does have at least an attempted implementation of IPv6 over
token-ring.

I have IPv6 configured on my Linux PC (kernel 2.4.18, using stock IPv6
implementation, not USAGI) at work (IBM) where I'm on a token-ring network
and an ethernet network.  I tried sending some ICMPv6 traffic out the
token-ring interface and bytes hit the wire, but Ethereal doesn't
recognize the packets as IPv6 traffic.  I looked at the packet data and I
can see the IPv6 header in there.  I don't know enough about token-ring to
know if all the bytes are correct.  Unfortunately, I don't think we
have another IPv6 enabled machine on the token-ring LAN at the moment to
test with.

Jason Maas
IBM Endicott, NY