Subject: Node Requirements update

From: [email-masked]
Date: Thu, 8 May 2003 12:33:22 +0300

Hi all,

I am starting to update the Node Requirements draft.  The main issues are to
handle the text for stateful address auto-configuration/ M & O bits & for DHCPv6 
support.  I will try to compose text and send it the the list before 
sending an updated draft to the list.

Notes from the San Francisco IETF meeting follow.

Thanks,
John
IPv6 Node Requirements, Open Issues -- John Loughney
----------------------------------------------------

<draft-ietf-ipv6-node-requirements-03.txt>

<reference John's slides>

John presented his open issues with his current version of IPv6 node
requirements.

---

Hesham Soliman asked about the DHCP support rewording re SHOULD or
MAY. Doesn't consider it to be useful. Doesn't need to be a SHOULD.

Dave Thaler asked Ralph Droms if there is still an interest in DHCP on
this?

Jim Bound felt stateful configuration is a MUST. M bit must be set. Node
can ignore. Customers that have stateful environments will not go to
stateless environments.

Christian disagreed. No question that we must support stateless. Market
will take care of this. MAY is enough.

Rob Austein said that John should separate question on this.

Bob Hinden, speaking personally, noted that he would not want to see
people have to implement functionality they don't need.

Perry Metzger felt that it doesn't matter which we choose as we are being
precise about how to be imprecise.

John wanted to know how to resolve. Bob Hinden asked who wanted to keep
the existing text (says MAY). In looking at the text to see if this was
the way to frame the question John decided it was best to send a proposed
change to the list so it could be discussed Thursday.

---

On privacy extensions for addr conf, Alain Durand said there are reverse
path dns issues when a random address may not resolve. Keith said it is
more general, and need an API for this.

Pekka asked if this is actually used. John said probably good to have the
code, but use can cause a problem so should be aware of that.

If per node basis things will break it should be done on a per API
basis. Seemed to be consensus to go with John's suggested text change.

---

Mobile IP - Routers SHOULD support the requirements set for all IPv6
routers. Several comments that this doesn't sound right.

Should be changed to routers SHOULD support mobile IP requirements.

---
Security - still questions. What level of security to document. Gave
example. 

Steve Belovin noted trying to get rid of DES. Thus should remove the
MUST. John will ask someone in security to review this.

Margaret noted that she liked the idea of separating security into a
separate draft. Steve Belovin wanted to take this off line.

John wants to hold off on the security section. He will edit the other
items and ask if it is ready for last call, barring the way security is
reviewed and/or changed.

Bob Hinden wants to defer the security issue as IPSEC isn't useful in
every device, e.g., a device that might want SSL or SSH for security, and
doesn't want IPSEC. So need to think about this broadly, thus should go
ahead without security for now to make progress.

Jim Bound said that if we want to revisit MUST that it is an IPSEC
job. Where do we stop if we do this. IPSEC is a MUST historically and IP6
is the front line of defense for security by using IPSEC to secure the IP
level.

Thomas concerned about a node requirements doc with no security. Need a
lot of help from security group to have a serious discussion on this.

John likes having a reference to a doc with current best current security
practices for IPSEC.

Keith doesn't like having IPSEC as it isn't really a solution.

Jim Bound said we could make a more specific by node type document rather
than this general approach. To alter the existing MUST/SHOULD with this
doc is bad idea as it would be in conflict.

Jim said he could do a review on MUSTS to see if anything should be
changed.

Keith felt that this specification should be for generic programmable
nodes. Maybe other specific, i.e., fixed function, devices should not be
covered by this. Margaret disagreed and noted that were many many of
these types of devices to consider.

Bob felt that the intro should note the scope re Keith's comment.

John will pose issues about stateful addresses and M & O bits, as well as
more discussion on security. Agreed that the wg needs to decide how to
handle security.

------------

John Loughney provides a quick update on the nodes requirement draft. The
big open issue was the state of the "stateful address auto-configuration"
requirement. The agreement on the mailing list is to have this rated as
"MAY support", for which John proposes a text; there is also a
requirement that if the WG eventually chooses to say that application
"SHOULD" support, there should be a strong qualifier authorizing
implementations to opt out. A show of hands shows 59 hands up for
preferring MAY, 21 for SHOULD; the chairs believe that this constitute
rough consensus in the room, but we need to verify the decision on the
mailing list.

Another update on the requirement draft is the state of requirement of
support for DHCPv6: must support if use for stateful address
autoconfiguration; should support for other configuration; may support if
no stateful or other configuration is needed. Christian Huitema asks for
clarification, whether the "other configuration" really means "stateless
DHCP". Thomas Narten asks whether we are making the explicit decision
that DHCPv6 is "THE" stateful address configuration mechanism? John
concludes that this specific paragraph needs further discussion on the
mailing list. Ralph asks for clarification of the handling of the M bit
and the O bit.

--------------------------------------------------------------------
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]
--------------------------------------------------------------------