[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Draft IPv6 Minutes from Atlanta IETF



Draft IPv6 working group minutes from the San Francisco IETF are attached.

Please review and send comments.

Thanks,
Bob
IPv6 Working Group (ipv6) Agenda
IETF 56, San Francisco

CHAIRS:
        Bob Hinden <hinden@iprg.nokia.com>
        Margaret Wasserman <mrw@windriver.com>

Minutes notes taken: 
        Bob Fink (March 17, 2003)
        Christian Huitema (March 20, 2003)

AGENDA:

Introduction and Agenda Bashing -- Bob Hinden  (5 min)
Updated Charter -- Bob Hinden (10 min)
Working Group Action Plan -- Margaret Wasserman (15 min)
Prefix Delegation:
 - Prefix Delegation Requirements -- Shin Miyakawa (10 min)
 - DHCP Option for Prefix Delegation -- Ole Troan (5 min)
 - Moving forward on Proxy RA Approach -- Bob Hinden (5 min)
IPv6 MIBs -- Margaret Wasserman (10 min)
IPv6 Addressing Architecture Appeal:
 - Overview of IAB Response -- Leslie Daigle (20 min)
 - Working Group Response to Appeal Process -- Margaret Wasserman (10 min)
Access Control Prefix RA Option -- Steve Bellovin (10 min)
IPv6 Node Requirements, Open Issues -- John Loughney (30 min)
Analysis of IPv6 Anycast -- Itojun Hagino (10 min)

DHCPv6 DNS Resolver Configuration Option -- Ralph Droms (10 min)
IPv6 over Fibre Channel Review Request -- Claudio DeSanti (5 min)
IPv6 Addressing Architecture
 - Review of IAB Recommendations & Next Steps -- Margaret Wasserman (30 min) 
Node-Requirements follow up (10 min)
Site-Local Addressing -- Bob Hinden and Margaret Wasserman (60 min)
IPv6 Socket API for source address selection -- Erik Nordmark (10 min)

=================================================
First Session:  Monday, March 17, 2003, 1930-2200
=================================================

Introduction and Agenda Bashing -- Bob Hinden
---------------------------------------------

Bob opened the meeting and reviewed the agenda. There were no changes to
the published agenda.

Updated Charter -- Bob Hinden
-----------------------------

<reference to Bob's slides>

As discussed in Atlanta, except:
 DNS Discovery removed from the charter
  ADs instructed chairs to remove work item (an explanation sent to
  working group mailing list) 
  topic will be discussed at DNSOP session

Goal for end of year is to either re-charter or close wg.

Primary wg responsibilities are:
 Completing work on the IPv6 working group documents
 Reviewing and updating IPv6 specifications based on implementation and
 deployment experience,  and advancing them on the standardization track
 as appropriate. 

Hinden presented a list of urgent work items and a list of current work.


Action Plan -- Margaret Wasserman
---------------------------------

<reference to Margaret's slides>

Margaret Wasserman presented document status and related actions.

Bob Hinden thanked the authors of flow label draft.

Itojun asked what the status of the anycast analysis draft is.  Margaret
said not clear if it was part of the work of the wg yet.  Need to decide.


Prefix Delegation: Prefix Delegation Requirements -- Shin Miyakawa
------------------------------------------------------------------

<draft-ietf-ipv6-prefix-delegation-requirement-01.txt>

<reference Shin's slides>

Shin Miyakawa presented his work on prefix delegation requirements.

Shin noted that he appreciated the Michel Py and Pekka Savola
comments. Shin outlined them to see if there was agreement with going
ahead with the draft with Pekka's changes or not. Michel Py said he was
willing to go with the current text without changes for his comments.

Margaret asked what the wg thought of the changes.

Brian Haberman said layer two work out of scope. On lifetime he thinks it
should cascade down. The wg agreed.

Margaret asked how many people thought PPP be included, or should this
layer two stuff be removed. Christian thinks there is a difference
between a serial link and a shared link. So don't have to say PPP, but
must note the difference.

Dave Thaler thinks PPP and CHAP stuff should go away. Needs to be a
mechanism that works on a shared link. Also prioritization should be
removed.

Margaret asked if PPP and CHAP should be removed: unanimous to remove.

Margaret asked if the Layer 2 auth should be removed: unanimous generic
layer 2 auth stuff to stay.

Sentiment expressed there be a requirement for a solution that works on a
shared link.

Jordi Palet stated that it needs a shared link solution.

Hesham Soliman asked why this was more complex? Shin said PPoE employed
as it is easy to identify customer equipment.

Francis Dupont agreed with PPoE, but need a shared link solution.

Margaret asked if we need a prefix delegation solution on shared link:
consensus was that we need a solution that does.

Shin will modify the draft and get out for further review as soon as
possible.


DHCP Option for Prefix Delegation -- Ole Troan
----------------------------------------------

<draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt>

<reference Ole's slides>

Ole presented his DHCP option for prefix delegation.

He felt that it was ready for wg last call. There were no comments.


Moving forward on Proxy RA Approach -- Bob Hinden
-------------------------------------------------

<no slides>

Bob talked on Proxy RA solution. If progress, we need to have volunteers
to work on draft to extract appropriate text from the multilink subnet
stuff.

Dave Thaler volunteered to work on this, but needs comments from folks
that it meets requirements. Ole thinks it my be useful but that it
doesn't meet all requirements.

Christian happy that Dave will do the job, and wants to excise the proxy
RA stuff from the multilink subnet draft, but there are problems with
home users stacking routers at home. So there is a need for multilink
subnet solution.

Dave expressed concern as to what people think RA proxy means as there
are different thoughts on this. Need input/comments to help.

No further comment. Presumably Dave Thaler will proceed to work on this
solution.


IPv6 MIBs: Forwarding, TCP & UDP MIBs Open Issues -- Margaret Wasserman
-----------------------------------------------------------------------

<draft-ietf-ipv6-rfc2096-update-02.txt>
<draft-ietf-ipv6-rfc2012-update-02.txt>
<draft-ietf-ipv6-rfc2013-update-00.txt>

<reference Margaret's slides>

Margaret presented a status report on various IPv6 MIB efforts. There
were few folk that have read this or that have any comments. Margaret
extolled folk to review and help forwarding these drafts.

Dave Thaler noted that he had read the TCP MIB and believes it is ready
for wg last call.

Generally there was agreement that these MIBs are needed, but very few
have read them and have an opinion on technical content.

Margaret noted that the UDP MIB needs an editor.

Someone asked if the OPS area have reviewed them. Margaret said they have
not and probably won't until forwarded. Margaret may mention these to the
OPS area at their meeting this week.

Dave Thaler outlined problem with the forwarding MIB. There is a problem
with interpretation of TOS byte. Brian Carpenter said he would review and
help resolve this.


IP MIB Open Issues -- Shawn Routhier
------------------------------------

<draft-ietf-ipv6-rfc2011-update-02.txt>

There was no presentation.  Incorporated in previous talk.


IPv6 Addressing Architecture Appeal
-----------------------------------

Overview of IAB Response -- Leslie Daigle
-----------------------------------------

<http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html>
<http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.txt>

<reference Leslie's slides>

Leslie presented a clarification of the IAB response to the Robert Elz
appeal in the IPv6 Addressing Architecture as there was some apparent
confusion of what the IAB was saying.  It does not say this draft should
not be forwarded. Nor does it give directive to the wg.

It does say this draft is not clear enough for a DS, and clarity needed
to ensure interoperable implementations.

Not challenging the IPv6 architecture. A future version may go to
DS. Some things are recommended to be fixed.

Not treading on IESG space. All further discussion to be in wg.

There were no comments.

Working Group Response to Appeal Process -- Margaret Wasserman
--------------------------------------------------------------

<no slides>

Margaret noted what further discussion on this topic would happen on
Thursday, specifically on how to respond to the comments, and then on
what to do with the draft.

Margaret asked wg folk to review the available information in preparation
for Thursday's meeting.

There were no comments.


Access Control Prefix RA Option -- Steve Bellovin
-------------------------------------------------
http://www.ietf.org/internet-drafts/draft-bellovin-ipv6-accessprefix-01.txt

<reference Steve's slides>

Steve presented on his access control prefix RA option draft.

Christian said the conclusion slide that this is not a security solution
is why Brian Zill's solution wanted to keep the mechanism simple.

Keith Moore asked if we want to build in network topology and addressing
coincidence. He felt there were similar problem with this approach as
with site-local, which Keith does not like.

Perry Metzger said this proposal demonstrated we should get rid of
site-local.

Dave Thaler noted access control mechanism has similar problem to Brian's
choice. Steve agreed.

Tony Hain noticed this is not really different than site-local. Margaret
disagreed and noted that there could be different prefixes with Steve's
approach.

Pekka Savola felt there are differences in Steve's approach and
site-local.

Dave Thaler agreed with Tony. Would prefer a change to the node
rules. Christian had similar comments.

Margaret noted that this is part of the greater site-local discussion to
take place later in the week (when Steve won't be available).

There was no further discussion as this will be revisited at Thursday's
meeting.


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.


Analysis of IPv6 Anycast -- Itojun Hagino
-----------------------------------------

<draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt>

<no slides>

Itojun presented a short status report on his analysis of IPv6
anycast. He has received some comments from Erik and he will generate a
new version but doesn't know if it should require a last call. Margaret
wanted to redo the w.g. last call this new draft as it has been a long
time since it was last reviewed.


===================================================
Second Session: Thursday, March 20, 2003, 0900-1130
===================================================

Bob Hinden presents the agenda. 60 minutes are left for the discussion of
the site local addressing issue.  Noted that original agenda items for
site-local are changed.  Now there will be a singe presentation jointly
presented by both chairs.


DHCPv6 DNS Resolver Configuration Option -- Ralph Droms
-------------------------------------------------------

<draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt>

Ralph Droms presents the state of DNS configuration in DHCPv6. There are
two DHCP options: DNS server and Domain search list. The DNS server
option has been adopted by the DHCP group, after some searching of the
proper option name, which turns out to be "recursive name server";
another issue was whether to carry IPv4 addresses as well as IPv6, which
was resolved by only carrying IPv6 addresses. The Domain search list
option is exactly copied from the similar DHCPv4 option. The two options
have passed DHCP WG last call. DHCPv6 is now a proposed standard, in the
RFC editor queue; implementations have been tested at TAHI
connecthaton. Work is ongoing on a stateless DHCPv6 subset, which allows
for a lightweight implementation. The stateless DHCPv6 draft needs review
from implementers, to make sure that it is written in a "developer
friendly" way.

Dave Thaler asks what the resolution is for the search path option, and
possible differences between a value returned over IPv6 and another
received over IPv4? Ralph answers that this will be left to the
host. Pekka Savola observes that there is the same issue with the DNS
server list; but for Ralph this is not a really issue. Rob Austein: the
choice of server is who you ask, but all are supposed to return the same
answer; the search string is what you ask, which changes the
answer. Alain Durand retorts that change in the calling order of servers
can affect the response delays, so some precision is important to avoid
operational problems. In any case, says Ralph, this is not really a
DHCPv6 issue: DHC specifies a configuration mechanism; choosing the order
of responses is a management option. The drafts will be updated to
include a short discussion of this point. For Keith Moore, the search
list mechanism is broken anyhow, and should not be used at all, so fixing
it is irrelevant. Alain Durand points out the analogy with the choice of
routers by hosts, which is indeed left to the host.


IPv6 over Fibre Channel Review Request -- Claudio DeSanti
---------------------------------------------------------

<draft-desanti-ipv6-over-fibre-channel-00.txt>

Claudio Desanti presents the work on IPv6 over Fiber Channel. FC is a
Storage Area Network. There is an IPv4 specification already, but we need
an IPv6 specification. IPv4 over FC defines its own ARP mechanism, but
for IPv6 they want to leverage Neighbor Discovery. FC channel nodes have
their own 64 bit identifier, but routing is based on volatile 24 bits
labels; an upper layer protocol manages a sequence of frames. Work in
ANSI T11 committee has defined how to map FC name identifiers into EUI 64
format. The draft defines how to generate a node identifier, how to map
link local Unicast and Multicast, and how to map the channel and exchange
management. The question to the IPv6 WG is what to do with the spec:
either an "IPv6 over FOO" work item in the IPv6 WG, or an individual
submission progressing to PS after IPv6 WG review. Margaret points out
that IPv6 over FOO is not in our charter anymore, so the second option
will have to be discussed with the AD. Pekka Savola observes that the
draft is very hard to read by someone not versed in FC. Thomas Narten
agrees with Margaret that the only role of the IPv6 WG should only be
tasked to provide a review. Greg Carlson, as Thomas, mentions that the
responsibility of the work should be in the TLC working group.


IPv6 Addressing Architecture- Review of IAB Recommendations & Next Steps
 -- Margaret Wasserman
------------------------------------------------------------------------

<http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html>
<http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.txt>

Margaret Wasserman presents the IPv6 WG response to the IAB
recommendations on Robert Elz appeal. The IAB response at several
sections, one presenting their conclusion, and another presenting their
recommendations. The recommendations are informative in nature, but they
cannot be ignored. The questions to answer are: is 64 bit a hard
boundary; what is the exact meaning of global scope, and what to do with
the U bit. Margaret engages in a review of each of these issues.

Is 64 bit a hard boundary? It is quite clear that all formats except
those with a 000 bit prefix have a hard 64 bit boundary. Review of the
text found a reference to CIDR that might be construed to envisage
aggregation of prefixes longer than 64 bits; this will have to be
fixed. Pekka Savola does not need it needs clarification; rather, we
should revise the whole concept, because otherwise some implementations
will stop prefix matching at 64 bits, which is in his mind broken. Thomas
Narten restates the IAB requirement: was there an already made
architecture decision on the 64 bits split , or is it left for further
discussion; for example, should applications be required to enable
routing on a /124? Margaret mentions that the only discussion is for the
0::/3 prefix. Bob Hinden mentions that the application only have to do
CIDR on the first 64 bits. The current specification of the 0::/3 prefix
is longest match to arbitrary length. We agree that the section is not
clear, and will have to be edited. Erik Nordmark mentions that the spirit
of the document is clear, the implementation requirement is not, and
there is still discussion in the operator community, e.g. allow /127 bit
prefix on PPP links. Jim Bound mentions that it is a well known fact that
we should not restrict prefix match to 64 bits. Thomas asks whether this
is actually the consensus of the group? Michel Py finds that the text is
clear, so asks what exactly is confusing about it? Margaret answers that
if the IAB cannot understand it there is an issue. Fred Templin mentions
that there may be some need in the future to match more bits than
64. Hashim mentions that there is a prefix length in the RA options; how
does the 64 decision affect RA processing? Keith Moore advocates that we
do not repeat the class-full address assignment mistake of IPv4; he
suggests that we keep a requirement for routers to match arbitrary length
tables.

The issue with global scope was a confusion between global scope and
global uniqueness; it assumes that any address with the U bit set is
globally unique. The proposal is to refer to the U bit as "universal",
and to reserve use of the adjective "global" for global scope
addresses. Erik Nordmark mentions that there is no requirement to
consider the U bit in routing processing. Fred Templin agrees with
Margaret. Keith Moore mentions that we should explicitly warn applications
to make no assumption about the structure of the address.

The interoperability requirements of the U bit were unclear; the appeal
pointed out that we did not show two implementations that tested the U
bit in an interoperable way. For Margaret, this is really a documentation
issue: implementations are not required to allocate any meaning to the U
bit and test its uniqueness; the U bit is only used as a way to construct
host identifiers. Bob Hinden believes that changing the text to not
require any test will remove the interoperability issue. Keith Moore goes
one further: applications should not assume that an identifier with the U
bit set is globally unique. This is pretty clear already, says
Margaret. Obviously, there is wide consensus in the room.

The IAB had 5 recommendations: publish the document at PS, which has
been approved; update the document to include clear and concise
interoperability requirement using RFC 2026 and 2119 language, which is
agreed with the WG with two reservations regarding the U bit (see above)
and the 2119 language; update the requirement for 64 bit identifiers,
which we discussed previously; and that we revise the ND and
auto-configuration specification to include the knowledge of the 64 bit
boundary, which will be considered when we update these document at a
later date. Margaret would like to thank the IAB for reviewing our
document and helping us make it stronger.


IPv6 Node Requirements, Follow Up -- John Loughney
--------------------------------------------------

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

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.


Site-Local Usage Discussion -- Margaret Wasserman & Bob Hinden
--------------------------------------------------------------

Margaret Wasserman opens the IPv6 site local discussion.  Presentation
done in round robin fashion by both chairs.

Goals for discussion: analyze options, reach consensus on approach. It is
important for WG to make a decision (don't want endless debate) chairs
will support whatever achieves consensus. There are several choices: get
rid of site local altogether; limit their use to disconnected sites;
create an exclusion requirement so nodes cannot configure both site local
and global addresses; a prohibition of nodes belonging to several sites;
and full usage. There are documentation for the "limited", "moderate" and
"full" options; the "exclusive" model is undocumented; there is WG
consensus to not support the "full" option, and as a consequence the
progress of the current scoped address architecture draft is frozen.

The limited model implies only using site locals in disconnected sites,
and requires renumbering when the site becomes connected. Margaret's
slide mention usage behind an IPv6 NAT; Keith Moore objects that this is
a license for NAT; Margaret agrees that the limited model could
imply the use of IPv6-IPv6 NAT.

The exclusive model mentions that nodes will never be configured with
both site local and global addresses. This simplifies address selection a
lot, but requires some form of host configuration. The exclusivity limits
the potential for leakage. Brian Carpenter asks what happens when a site
is oscillating between connected and disconnected; Bob Hinden answers
that in the exclusive state, the globally addresses nodes will simply
become unreachable when the site is disconnected. Alain Durand asks for
clarification. Thomas suggests that this would become a router
advertisement restriction, but this becomes hard to enforce when there
are several routers on a link. Margaret restates the intention: even if
hosts receive advertisements for both type of prefixes, a host
configuration bit will govern which type of address gets
configured. Alain Durand observes that if there is no enforcement
mechanism, this exclusion requirement is totally useless. Jim Chang
states something that the note taker could not understand. Michel Py
suggests that we should make global and site local exclusive on a given
subnet. Thomas wonders whether there are open issues in this proposal,
and this is hard to assess in the absence of a formal document. Keith
Moore wonders how that applies to hosts with multiple interfaces, which
seems unwieldy. Marc Blanchet asks whether the requirement applies to
routers? Answer: Yes. Erik Nordmark wonders whether a single link would
have a site local printer and another global scope host; the answer is
yes. Pekka Savola mentions that if nodes also mention routers, then we
should say so explicitly, as it has wide consequences on routing.

The moderate model allows for site local addresses if they are
explicitly configured. Nodes can have both type of address. A site border
router will be in exactly one site, with some interfaces in no site at
all. We will have to revise the address selection algorithms to not
prefer site local, and revise a couple of other documents as well.

The benefit of the limited model is that it allows addressing for
disconnected sites.  Christian Huitema pointed out that Margaret's
references to IPv6<->IPv6 NAT were divisive and unnecessary, and said
that Margaret was trying to link the limited model to IPv6 NAT.  Margaret
said that the limited model could be used behind IPv6 NAT or NAT-PT, but
did not require the use of either type of NAT.  Margaret agreed that the
topic of IPv6 NAT was divisive and agreed that, in retrospect, it would
have been better not to include it on the slides.  For Margaret, the
exclusive model has the additional benefit that it allows stable
addressing for local nodes.

Bernard Thuy observes that this discussion never took multicast into
account; what is the impact?  Brian Carpenter points out that the limited
model has a benefit not carried in the other model, i.e. simplifies the
handling of addresses by applications. Alain Durand challenges the stated
benefit of the exclusive model: nodes that have global addresses will
have to oscillate between the two types of addresses. The moderate model
has additional benefits: it allows stable addressing, and easy
communication.

The issue list included: IP layer address leaking; IP address selection
issues; DNS address leaking; address leaking by other layers; handling of
boundaries in routing protocols; forwarding table issues; and mobile IP
issues.

IP layer address leaking is addressed by all proposal. Limited and
exclusive do not require changes to address selection rules; moderate
requires switching the order of preference. Exclusive and moderate need
enforcement mechanism to avoid leaking in the DNS. Limited does not have
a leakage problem in applications, since there is no connectivity;
exclusive probably eliminates the issue as well; moderate requires upper
layers to incorporate some address selection rules. All proposals
eliminate the routing protocol issues, as well as the forwarding table
issues, as no proposal allows a router to be in more than one site at the
same time. The limited proposal eliminates the possibility to support
mobility out of the site; exclusive and moderate requires mobile nodes to
use global addresses.

As a summary, limited eliminates most problems, but it also eliminates
all the benefits. Exclusive does not have the issue of requiring handling
of scoped addresses in applications. Bob think it important that the
working group gets consensus on the issue. Margaret tries to impress the
need that we have to reach a decision today: choose between the 4
options, or possibly excise the site locals from the scope address
document, and just consider global and site locals.

Pekka Savola believes that the exclusive option as presented is broken;
it is only usable in limited cases, e.g. placing a few local nodes in an
otherwise global link; the only reason is to restrict access to nodes,
which can be node by the less intrusive access prefix option. Alain
Durand believes that the analysis of address leakage is wrong: we have an
implementation of that model with RFC 1918 today, and addresses do leak;
Margaret believes that this is due to implementation mistakes, which
raises some heckles; Alain believes that the only way to avoid the issue
is not use site locals at all. Keith Moore believes that IPv6 will not be
useful as long as we don't support site local; reserving the site local
addresses to disconnected sites will not work, as proven by the RFC 1918
experience. Matt Mathis wants to reinforce Keith's point: looking work at
the early ways of the ROAD WG, having applications consider the scope of
addresses was already consider a bad idea then, and is still a bad idea
now; we should not require applications to know anything about the scope
of addresses. Brian Haberman believes that any analysis of the issues is
bound to be incomplete, and would support an option to just excise the
site local addresses from the scoped address architecture; as an editor
of the scoped address document, Brian proposes to just do that. Fred
Templin believes that site locals will benefit intermittently connected
sites. Michel Py supports the exclusive model as a way to move forward,
if it is enforced on the entire link.

Erik is concerned that we don't have enough information to decide yet,
because we don't have consensus on requirements; for example, the
requirement to renumber without breaking connections triggers lots of
complexity for mobile nodes; the requirement of a security boundaries can
be solved in other ways; disconnected sites should be able to use global
addresses in most cases; and we don't have to make it easy to implement
NATs. Christian Huitema suggests that the exclusive model is an illusion;
it is not documented yet, and the devil is in the details; it is also not
enforceable, as nodes who want both addresses just have to pretend that
they have two link local addresses. Hesham Soliman agrees with Christian
that the exclusive model is a charade. Rob Austein agrees with Erik
Nordmark and Christian Huitema; thanks the chair for pointing out that
all solutions solve the IP issue, and that only the limited model solves
the application issue. Leif Johansson points out the very strong
requirement that applications don't have to care with address scope. Dino
Farinacci points out that a disconnected site can in fact use any prefix,
his disconnected site uses 2001::/16; he does not need that we need site
local addressing. Mohsen Feci wonders whether we really need site local
addresses; IPv6 addresses are not rare; not having site local addresses
to solve the problem. Kurtis Lindqvist points out that all proposal force
the network to maintain some state; that the site local costs us more
than it brings. Someone points out that the main benefit of IPv6 is
global addresses; we can just use global addresses. Samita adds her voice
to the idea of elimination of site local. Christian Huitema will prefer
eliminating site local over adopting the "limited" option. Thomas Narten
wonders whether the consensus in the room is for shifting towards
eliminating site local.

Bob and Margaret have a private conversation where they discuss how to
proceed to measure w.g. consensus.

Keith Moore would like to make an offer; observes that we cannot
eliminate the site local, but that we should actively study alternatives
for their various proposed use.  He suggest that we write a document that
deprecates the usage of site-local addresses and includes in that document
ways of obtaining the features of site-local addresses using global IPv6
addresses.

Marc Blanchet is afraid that if we forget about site local now, they will
be invented back later. Dave Thaler mentions the zerouter BOF, which
needs a recommendation for how to automatically configure a disconnected
network. For Erik Nordmark, if we eliminate site local, we have to remove
the currently existing code that handles FEC0::/10. Brian Carpenter
comments that RFC 1597 was one of the worse end runs in the history of
the IETF, and that interaction with NAT is clearly out of our control;
however, he would prefer to deprecate these addresses. Fred Templin
believes that we will still need a solution for intermittently
disconnected sites; this problem should be addressed. Jim Bound points
out that IPv4 NAT is a national security problem, and that an attempt to
control them are misguided. Keith Moore repeats the requirement that
applications should not be concerned with the scope of addresses.

Margaret asks the question, do we want to deprecate site local addresses?
There are 20 hands up for not deprecating, 102 hands up for deprecating;
This is interpreted as rough consensus to deprecate site local
addressing; this consensus will have to be verified on the mailing list.


IPv6 Socket API for source address selection -- Erik Nordmark
-------------------------------------------------------------

[No time for this talk]


------------------------------------------------------------------
------------------------------------------------------------------
Meeting Adjourned
------------------------------------------------------------------
------------------------------------------------------------------