Subject: Next steps on the IPv6 Node requirements draft

From: <[email-masked]>
Date: Tue, 17 Jun 2003 14:14:12 +0300

Hi all,

I've updated the draft on 4 major points that were discussed at the IETF.  Roughly
they cover stateful address autoconfig support, DHCP support, MIPv6 support and DES
support.

I want to get a sense of the WG, if it would be OK to send the updated draft out
and ask for a WG last call.  I have an issue tracker created, to help out on 
the WG last call that I would like to use 
(http://danforsberg.info:8080/draft-ietf-ipv6-node-requirements/index) and I'd
probably like to get some expert reviews, especially for the security sections.

What does the group think?  If it is OK with the WG, I could send the updated draft
out by the end of the week.

I have included the text that I have updated at the end of the mail.

thanks,
John

1) Stateful Address Autoconfiguration text:

 Stateful Address Autoconfiguration MAY be supported. DHCP [DHCPv6] is the standard 
 stateful address configuration protocol, see section 5.3 for DHCPv6 support. 

 For nodes which do not support Stateful Address Autoconfiguration, the node 
 may be unable to obtain any IPv6 addresses aside from link-local addresses when 
 it receives a router advertisement with the 'M' flag (Managed address configuration) 
 set and which contains no prefixes advertised for Stateless Address Autoconfiguration 
 (see section 4.5.2).

2) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Updated to:

 5.3.1 Managed Address Configuration

 An IPv6 node that does not include an implementation of DHCP will be unable to obtain 
 any IPv6 addresses aside from link-local addresses when it is connected to a link over 
 which it receives a router advertisement with the 'M' flag (Managed address configuration) 
 set and which contains no prefixes advertised for Stateless Address Autoconfiguration (see 
 section 4.5.2). An IPv6 node that receives a router advertisement with the 'M' flag set and 
 that contains advertised prefixes will configure interfaces with both stateless 
 autoconfiguration addresses and addresses obtained through DHCP.

 For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a 
 Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462).  In addition, in 
 the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP.

 An IPv6 node that does not include an implementation of DHCP will be unable to dynamically 
 obtain any IPv6 addresses aside from link-local addresses when it is connected to a link over 
 which it receives a router advertisement with the 'M' flag (Managed address configuration) set 
 and which contains no prefixes advertised for Stateless Address Autoconfiguration (see section 
 4.5.2).  In this situation, the IPv6 Node will be unable to communicate with other off-link 
 nodes unless a global or site-local IPv6 address is manually configured. 

 5.3.2 Other stateful configuration

 DHCP provides the ability to provide other configuration information to the node. An IPv6 
 node that does not include an implementation of DHCP will be unable to obtain other 
 configuration information such as the addresses of DNS servers when it is connected to 
 a link over which the node receives a router advertisement in which the 'O' flag ("Other 
 stateful configuration") is set.

 For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of 
 a Router Advertisement with the 'O' flag set (see section 5.5.3 of RFC2462).  In addition, 
 in the absence of a router, hosts that implement DHCP MUST attempt to use DHCP. For IPv6 
 Nodes that do not implement DHCP, the 'O' flag of a Router Advertisement can be ignored.  
 Furthermore, in the absence of a router, this type of node is not required to initiate DHCP.

3) Mobile IP requirements for routers updated to:

 Routers SHOULD support mobile IP requirements.

4) DES support removed:

 The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD NOT be supported. 
 Security issues related to the use of DES are discussed in [DESDIFF], [DESINT], 
 [DESCRACK]. It is still listed as required by the existing IPsec RFCs, but as it is 
 currently viewed as an inherently weak algorithm, and no longer fulfills its intended role.

--------------------------------------------------------------------
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: Peter Bell <[email-masked]>
Date: Wed, 18 Jun 2003 09:09:17 +1000

Along with removing DES from the "SHALL" list, it looks likely that AES
will be added to the IPSec SHALL requirements, perhaps this draft should
include AES.

Peter.

-- 
//
//  Peter L. Bell         [email-masked]
//                        +61 2 9805 2955
//  Blessed are the Peacemakers, they shall be called Sons of God.
//
--------------------------------------------------------------------
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: Alain Durand <[email-masked]>
Date: Wed, 18 Jun 2003 17:23:05 -0700

[email-masked] wrote:

> Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462).
>
So what if the M bit is set _and_ a prefix is advertized?
Should the node give up its stateless autoconfigured address in favor of 
DHCP?
What about statically configured addresses on the same node?

IMHO, it makes little sense to have both a DHCP allocated address and a 
stateless
autoconfigured address on the same interface. However, I see cases where 
you want
to have nodes using DHCP and nodes using stateless autoconfiguration on 
the same link.

    - Alain.

---

From: Robert Elz <[email-masked]>
Date: Thu, 19 Jun 2003 17:56:37 +0700

Date:        Wed, 18 Jun 2003 17:23:05 -0700
    From:        Alain Durand <[email-masked]>
    Message-ID:  <[email-masked]>

  | So what if the M bit is set _and_ a prefix is advertized?
  | Should the node give up its stateless autoconfigured address in favor of 
  | DHCP?

No, it should do both.

  | What about statically configured addresses on the same node?

It should keep that as well, though often if there's to be static
config it will often also be the case that use of stateless autoconfig
and dhcp config will be disabled (either explicitly or implicitly)

  | IMHO, it makes little sense to have both a DHCP allocated address and a 
  | stateless autoconfigured address on the same interface.

In that case, you wouldn't config your routers to send the M bit, and
prefixes with the A bit set, at the same time.

On the other hand, others may consider it useful to allow nodes to
autoconfigure themselves addresses (so they always gave one, provided
there's a working router to make the address useful) and at the same
time, provide specific addresses to specific nodes (attempting to use
DHCP doesn't necessarily mean the DHCP server will actually allocate
an address) where specific nodes are expected to own well known addresses.

  | However, I see cases where you want
  | to have nodes using DHCP and nodes using stateless autoconfiguration on 
  | the same link.

The very nature of *stateless* autoconfig is that there's no (easy) way to
configure a node to not do it (manual config on that node excepted).   If
there was, it would not be stateless.   So, by default, if any node on a
link is permitted stateless autoconfig (of a prefix) all nodes are.

It is generally harmless to own an extra address though, having the
statelessly configured one, as well as a dhcp supplied one should not
cause any harm.

That is, I don't think receiving a DHCP allocated address should cause
an autoconfig'd address to be dropped, there's no need (doing do raises
all the questions of what you do if you've been running using the
autoconfig'd address for hours when the dhcp server returns to life
and allocates you an address).

All that being said - a request to implementors out there.   It would be
very (*very*) nice to have the ability in a node to ignore prefixes
that are being advertised from routers, and never autoconfig an address
in that prefix.   That is, I occasionally see someone advertising a
prefix that I know doesn't work (they're getting ready for the day it
will work, and have just jumped the gun - believing in early preparation
or something).   I'd like to be able to ignore that (no matter what
router advertises it - so lower level packet filtering doesn't help).

kre

---

From: Alain Durand <[email-masked]>
Date: Thu, 19 Jun 2003 09:07:26 -0700

> statelessly configured one, as well as a dhcp supplied one should not

Not sure. Two reasons:
	- There may be filters in place, for example that only
	   allows DHCP assigned addresses to go out.
	   (this is not pure fantasy, I've heard people willing to do just 
that in hot spots).

	- There are reverse DNS issues. They may point to 2 different names or
	  more likely, the stateless autoconfigured address won't resolve to
	  a name, where the DHCP one will. As default address selection does
	  not (yet?) say to prefer the DHCP one, logs and/or (very) weak 
security/authentication
	  mechanisms based on DNS reverse lookup will work randomly.

- Alain.

---

From: [email-masked]
Date: Fri, 20 Jun 2003 11:04:31 +0900

>	  mechanisms based on DNS reverse lookup will work randomly.

	we don't have any standard wrt DNS registration of autoconfigured
	addresses, so you can't say that "stateless autoconfigured addresse
	won't resolve to a name".  the end node could register PTR record
	by DNS dynamic update, for instance.

itojun

---

From: Alain Durand <[email-masked]>
Date: Thu, 19 Jun 2003 19:13:09 -0700

Itojun,

I guess you missed the "more likely" part of my sentence.
I agree we don't have any standard wrt DNS registration of 
autoconfigured
addresses, and the current deployment practices show that it is a pain
to do it either manually or with dnsupdate (you have a key distribution 
problem),
so the reality is that they are seldom published and are not likely to 
resolve.

	- Alain.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 25 Jun 2003 07:30:44 -0400

Regarding reverse DNS entries ... there is a specific problem
with reverse DNS entries for autoconfiguration addresses regarding
update of the reverse entries by the client.

The portion of the DNS namespace into which the host wants to
insert its reverse DNS entry is owned by the network to which
the hose is attached.  There is no requirement for any
administrative or trust relationship between the host and the
network to which it is attached, so performing

The problem here is that administrative responsibility for
an autoconfiguration address ('ownership') is split: the
network admin owns the prefix and the host owns the suffix.
But the network admin owns the DNS namespace to which the
prefix belongs and must make an admin decision about wherher
to allow updates from a host with which it has no
administrative or trust relationship.

There are solutions - disallow reverse DNS updates for
autoconfiguration addresses, let the DNS server that maintains
the prefix allow untrusted updates in the namespace for that
prefix, require some DNSSEC trust mechanism that supports
roaming.

- Ralph

At 09:07 AM 6/19/2003 -0700, Alain Durand wrote:

>            (this is not pure fantasy, I've heard people willing to do 
> just that in hot spots).
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 25 Jun 2003 07:22:57 -0400

I agree with kre - address configuration through DHCP (confrolled
by 'M' bit) and autoconfiguration through advertised prefixes
should be considered independent.  An interface may well have
both autoconfiguration addresses and addresses obtained through
DHCP (and manually configured addresses, as well).

BTW, is there a differentiation here between the behavior of
hosts and routers in the processing of advertised prefixes and
the 'M' bit?  Is that differentiation explicitly documented
somewhere?  Is the node requirements document sufficiently
clear?

- Ralph

---

From: Derek Fawcus <[email-masked]>
Date: Fri, 27 Jun 2003 17:03:29 +0100

> update of the reverse entries by the client.

 [ snip ]

> prefix, require some DNSSEC trust mechanism that supports

Or a simpler approach - make use of ICMP name lookups.

Ask the end node it's name,  then check the name/address relationship
in the forward DNS (which we have to assume has been updated to point
to the address).

DF