Subject: IPv6 working group agenda for Minneapolis IETF

From: Bob Hinden <[email-masked]>
Date: Wed, 13 Mar 2002 16:51:41 -0800

The draft agenda is attached.  When we put together the agenda we give 
priority to work the chairs and AD's thought was most important.  There 
were a number of request for agenda slots that could not be 
honored.  Suggest these topics be brought to the mailing list.

Thanks,
Bob Hinden & Steve Deering

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

MONDAY, March 18, 2002, 1930-2200						
Introduction, Steve Deering, 5 min.

Review Agenda, Steve Deering, 5 min.

Document Status, Bob Hinden, 15 min.

Moving IPv6 Documents to Draft Standard, Margaret Wasserman, 30 min.

IPv6 Node Requirements, John Loughney, 10 min.

Default Address Selection for IPv6, Rich Draves, 0 min.
    <draft-ietf-ipv6-default-addr-select-07.txt>

Default Router Preferences and More-Specific Routes, Rich Draves, 15 min.
    <draft-ietf-ipv6-router-selection-01.txt>

DNS Discovery Update, Dave Thaler, 15 min.
    <draft-ietf-ipngwg-dns-discovery-04.txt>

IPv6 Node Requirements, John Loughney, 5 min.

Minimum IPv6 Functionality for a Cellular Host, Hesham Soliman, 30 min.
    <draft-ietf-ipv6-cellular-host-00.txt>

Minimum Requirements of IPv6 for Low Cost Network Appliances, Atsushi
Inoue, 10 min.
    <draft-okabe-ipv6-lcna-minreq-01.txt>

THURSDAY, March 21, 2002 min.

Prefix Delegation Intro, Steve Deering, 10 min.
    Automatic Prefix Delegation Protocol for IPV6, Brian Haberman , 10 min.
       <draft-haberman-ipngwg-auto-prefix-01.txt>
    DHCPv6 Prefix Delegation, Ralph Droms, 10 min.
       <draft-troan-dhcpv6-opt-prefix-delegation-00.txt>
    IPv6 Router Advertisement Prefix Delegation Option, Nathan Lutchansky,
    10 min.
       <draft-lutchann-ipv6-delegate-option-00.txt>
    Prefix Delegation Discussion, Steve Deering, 15 min.

IPv6 Flow Label Specification, Jarno Rajahalme, 45 min.
    <draft-ietf-ipv6-flow-label-00.txt>

Reserving bits in RFC 2473 Interface IDs?, Erik Nordmark, 20 min.

Make IMEI-based universal IPv6 interface IDs a w.g. Draft?, Francis
Dupont, 5 min.
    <draft-dupont-ipv6-imei-00.txt>

Scoped Address Architecture Update, Tatuya Jinmei, 10 min.
    <draft-ietf-ipngwg-scoping-arch-03.txt>

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

--------------------------------------------------------------------
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: Fri, 15 Mar 2002 10:56:51 +0200 (EET)

> honored.  Suggest these topics be brought to the mailing list.

As there was unfortunately no time, I'd like to ask your feedback on:

http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-hosts-00.txt
http://www.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-01.txt

Rh-hosts draft hasn't generated much of discussion since it left mobile-ip
working group.  I believe this will become unnecessary when host
requirements includes similar discussion.  But do we have to do something 
in the interim period?

127-prefixlen has genererated quite a lot of discussion, both back in 
Novermeber and now, and we seem to have reached some kind of a consensus 
on the contents.  The most important question I stated for which there 
have replies is, what should be do with this?  E.g.:

 1) this is a non-issue, no need to do anything
 2) wait for e.g. router requirements (could take 
    a long time), what to do in the mean time?
 3) push for individual informational
 4) adapt as w.g. document, push for informational
 
 others?

This is something I'd have liked to gauge in the w.g. meeting.

-- 
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: Ralph Droms <[email-masked]>
Date: Mon, 18 Mar 2002 11:55:32 -0500

I read through RFC 2462 to find out the requirements level for host use of 
the 'O' flag field ("other stateful configuration") in RAs.  The only text 
I found concerning the 'O' flag is"

(section 4, Protocol Overview)

    Solicitations to the all-routers multicast group.  Router
    Advertisements contain two flags indicating what type of stateful
    autoconfiguration (if any) should be performed. A "managed address
    configuration" flag indicates whether hosts should use stateful
    autoconfiguration to obtain addresses. An "other stateful
    configuration" flag indicates whether hosts should use stateful
    autoconfiguration to obtain additional information (excluding
    addresses).

(section 5.2, Autoconfiguration-Related Variables)

       OtherConfigFlag  Copied from the O flag field (i.e., the "other
                        stateful configuration" flag) of the most
                        recently received Router Advertisement message.
                        The flag indicates whether or not information
                        other than addresses is to be obtained using the
                        stateful autoconfiguration mechanism. It starts
                        out in a FALSE state.

                        In addition, when the value of the ManagedFlag is
                        TRUE, the value of OtherConfigFlag is implicitly
                        TRUE as well. It is not a valid configuration for
                        a host to use stateful address autoconfiguration
                        to request addresses only, without also accepting
                        other configuration
                        information.

(section 5.5.3,  Router Advertisement Processing)

    An advertisement's O flag field is processed in an analogous manner.
    A host copies the value of the O flag into OtherConfigFlag. If the
    value of OtherConfigFlag changes from FALSE to TRUE, the host should
    invoke the stateful autoconfiguration protocol, requesting
    information (excluding addresses if ManagedFlag is set to FALSE).  If
    the value of the OtherConfigFlag changes from TRUE to FALSE, the host
    should continue running the stateful address autoconfiguration
    protocol, i.e., the change in the value of OtherConfigFlag has no
    effect. If the value of the flag stays unchanged, no special action
    takes place. In particular, a host MUST NOT reinvoke stateful
    configuration if it is already participating in the stateful protocol
    as a result of an earlier advertisement.

So, RFC 2462 only uses RFC 2119 keywords to describe the behavior of a host 
when the value of the 'O' flag remains unchanged.  The text in section 
5.5.3 needs to be updated to:

    If the value of OtherConfigFlag changes from FALSE to
    TRUE, the host MUST invoke the stateful autoconfiguration
    protocol [...]

    If the value of the OtherConfigFlag changes from TRUE
    to FALSE, the host SHOULD continue running the stateful
    address autoconfiguration protocol [...]

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Mon, 18 Mar 2002 19:02:02 +0200 (EET)

>     address autoconfiguration protocol [...]

Strongly disagree.  This would make about every IPv6 implementation not
supporting stateful protocols non-compliant.

In my view 'O' is just a hint to the nodes that thay should try to use a 
stateful mechanism (as there is one in the specific network), if they have 
one.

---

From: [email-masked]
Date: Tue, 19 Mar 2002 02:05:17 +0900

>    TRUE, the host MUST invoke the stateful autoconfiguration

	you have changed "should" into "MUST".  any reasons why? what happens
	if a host does not have stateful autoconfiguration protocol
	implementation?

	i think "SHOULD" is fine.

itojun

---

From: Ralph Droms <[email-masked]>
Date: Mon, 18 Mar 2002 12:22:18 -0500

OK, there are really several issues here:
a. the text needs to be updated to use RFC 2119 keywords
b. which keywords?
c. what is "the stateful configuration protocol"?
d. if the answer to "c" is DHCPv6, should RFC 2462 more
    explicitly reference the configuration-only version
    of DHCPv6 in the description of the 'O'flag?

Without fixing a. RFC 2462 is underspecified in this area.

I changed "should" into "MUST" because a network manager who wants hosts to 
use "the stateful configuration protocol" really expects those hosts to use 
it.  It seemed like a good way to kick of the discussion.

Now that the DHCPv6 spec is approaching completion, we ought to talk about 
c. and d.

- Ralph

---

From: Brian Haberman <[email-masked]>
Date: Mon, 18 Mar 2002 12:57:26 -0500

Ralph,
     I agree the text should be updated.  To address your points 'c'
and 'd', it should be pointed out that 2462 was written so that there
was no dependency upon a particular stateful configuration protocol.
Operators would simply utilize their protocol of choice (DHCPv6 or foo)
and 2462 would allow that to be advertised to the hosts.

Brian

---

From: "Murugan KAT" <[email-masked]>
Date: Tue, 19 Mar 2002 00:06:36 +0530

Hi,

Regarding Dual Stack Router implementation should a router maintain 2
routing tables, one for V4 and other for V6. What about the routing stacks?
Should there be 2 instances of a routing protocol (BGP, OSPF etc.,) ?

What is the general approach?

Thanks,
KAT

---

From: "Murugan KAT" <[email-masked]>
Date: Tue, 19 Mar 2002 12:44:32 +0530

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Murugan KAT
Sent: Tuesday, 19 March 2002 12:07 AM
To: 'IPng List'
Subject: RE: Requirements for 'O' flag (was Re: IPv6 working group
agendafor Minneapolis IETF)

Hi,

Thanks,
KAT

---

From: Robert Elz <[email-masked]>
Date: Tue, 19 Mar 2002 19:29:31 +0700

Date:        Tue, 19 Mar 2002 02:05:17 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	what happens
  | 	if a host does not have stateful autoconfiguration protocol
  | 	implementation?

I just wanted to respond to this sub-issue...

If the network admin has specified stateful autoconfig, and the host
doesn't implement it, then the host MUST fall back on manual configuration.
It MUST NOT decide to just ignore the O bit and autoconfigure itself
some other way.

But as manual configuration always wins any argument, that's always an
option for any host (and any that don't support any kind of manual config,
and don't support stateful config, simply cannot function on a net where
stateless autoconfig is disabled).

kre

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 20 Mar 2002 14:51:14 +0900

>>>>> On Mon, 18 Mar 2002 12:57:26 -0500, 
>>>>> Brian Haberman <[email-masked]> said:

> and 2462 would allow that to be advertised to the hosts.

I agree.  How much a spec should be specific is always a tradeoff (if
it is too generic, implementors and operators will be confused against
so many choices.  if it is too specific, we'll kill future
extensions), but in this case, I think it is overspecification to
restrict the possibility to DHCPv6.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Josh Littlefield <[email-masked]>
Date: Wed, 20 Mar 2002 20:47:52 -0500

> restrict the possibility to DHCPv6.

That may be, but I don't understand how the host would know how to interpet
the 'O' bit if it means "do what the operator has decided is correct."
If the hosts must be preconfigured to make sense of the 'O' bit, or the
'M' bit for that matter, then I think we've lost quite a bit of utility.

In any event, I read 2462 to imply that DHCPv6 is the intended protocol for
stateful autoconfiguration of addresses and/or configuration information, by
its reference in section 1, but it's certainly implicit, not explicit.

The text, and client behavior, need to be clarified one way or the other.

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                                      250 Apollo Drive
tel: 978-497-8378  fax: same               Chelmsford, MA  01824-3627
--------------------------------------------------------------------
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]
--------------------------------------------------------------------