IPv6 WG Minutes
July 14 & 17, 2003
IETF57 -- Vienna, Austria
=========================
CHAIRS: Bob Hinden <hinden@iprg.nokia.com>
Margaret Wasserman <mrw@windriver.com>
Minutes taken by Margaret Wasserman and Bob Hinden.
AGENDA:
Monday July 14, 2003
Introduction and Agenda Bashing -- Bob Hinden (5 min)
Document Status and Priorities -- Bob Hinden (10 min)
Open Issues with IPv6 Node Requirements -- John Loughney (15 min)
Open Issues with IPv6 MIBs -- Brian Haberman (10 min)
Open Issues with Prefix Delegation Requirements -- Shin Miyakawa (10
min)
Bridge-like Neighbor Discovery Proxies -- Dave Thaler (15 min)
IPv6 Node Information Queries -- Bob Hinden (15 min)
IPv6 Socket API for source address selection -- Samita
Chakrabarti (10 min)
Link Name and Sequence Options for IPv6 Neighbor Discovery -- Naiming
Shen (5 min)
Thursday, July 17, 2003
Introduction and Agenda Review -- Bob Hinden (5 min)
Open Issues with Scoped Address Architecture -- Jinmei Tatuya (10 min)
Requirements for Local Addressing:
Local Addressing Requirements -- Tony Hain & Juha Wiljakka (20 min)
General Discussion of Local Addressing Requirements -- Chairs (30 min)
Unique Local IPv6 Unicast Addresses -- Bob Hinden (20 min)
Site-Local Deprecation Document Plan -- Christian Huitema (30 min)
----------------------------------------
------------------------------
Introduction and Agenda Bashing -- Bob Hinden
---------------------------------------------
Bob Hinden announced an IPv6 Interoperability event in September in
Brussels. For more information see:
http://www.etsi.org/plugtests
Reviewed the agenda. Plan is to discuss short topics and normal
business today, and use Thursday primarily for local discussion topic.
There were no comments or changes to the agenda.
Document Status and Priorities -- Bob Hinden
--------------------------------------------
Review of Charter Milestones
Revised Current Description
------- -------
-----------------------------------------------------
Done Submit A Flexible method to manage the assignment of bits
of an IPv6 address block to the IESG for Informational.
Done Submit Flow Label specification to IESG for Proposed
Standard.
Jul 03 Mar 03 Submit Prefix Delegation requirements and submit to IESG
for Informational.
Done Revise Aggregatable Unicast Addresses (RFC2374) to
remove TLA/NLA/SLA terminology.
Done Apr 03 Draft on Proxy RA solution for prefix delegation.
Oct 03 Apr 03 Submit update to ICMPv6 (RFC2463) to be
republished at Draft Standard.
Jul 03 Apr 03 Submit TCP MIB to IESG for Proposed Standard.
Aug 03 Apr 03 Submit IPv6 Node Requirements to IESG for
Informational.
Aug 03 May 03 Submit Forwarding Table MIB to IESG for Proposed
Standard.
Aug 03 May 03 Resubmit Node Information Queries to IESG for
Proposed Standard.
Sep 03 May 03 Submit UDP MIB to IESG for Proposed Standard.
Aug 03 Jun 03 Submit IP MIB to IESG for Proposed Standard.
Oct 03 Jun 03 Submit Router Preferences, More-Specific Routes, and Load
Sharing to IESG for Proposed Standard
Dec 03 Jun 03 Submit updates to Auto Configuration (RFC2462) and
Neighbor Discovery (RFC2461) to be republished at Draft Standard.
Dec 03 Jun 03 Submit Update to Privacy Extensions for Stateless
Autoconfiguration document (RFC3041) to the IESG for Draft Standard.
Dec 03 Jul 03 Submit Proxy RA to IESG for Proposed Standard.
Sep 03 Jul 03 Submit Link Scoped IPv6 Multicast Addresses to IESG for
Proposed Standard.
Aug 03 Submit IPv6 Scoped Addressing Architecture to IESG for
Proposed Standard
DROP? Aug 03 Submit update to IPv6 over PPP (RFC2472) to IESG for
Draft Standard.
Jan 04 Nov 03 Re-charter or close working group.
James Kempf asked if the Neighbor Discover changes are related to a
mobility draft on Friday. Bob Hinden explained that we are making
updates for minor issues and hope to recycle at Draft Standard. Major
changes or new features should be considered independently.
Discussion of dropping PPP. Alex Conta thinks that we should update it for
specific changes, which he will send to the list.
Document Status
Published & Approvals
- RFC's Published
o RFC 3316 "Internet Protocol Version 6 (IPv6) for Some Second and
Third Generation Cellular Hosts"
o RFC 3513 "Internet Protocol Version 6 (IPv6) Addressing
Architecture"
o RFC 3531 "A Flexible Method for Managing the Assignment of Bits of an
IPv6 Address Block"
o RFC 3542 "Advanced Sockets Application Protocol Interface (API) for
IPv6"
- IESG Approved
o "IPv6 Global Unicast Address Format"
Flow Label
- Editor: Jarno Rajahalme
- Status: In IETF Last Call
- Milestone: DONE
o Submit for PS
- Open Issues:
o None
Global Unicast Addresses
- Editor: Bob Hinden
- Status: IESG Approved
- Milestone: DONE
o Submit for Info
- Open Issues:
o None
Proxy RA
- Editor: Dave Thaler
- Status: New draft
- Milestones:
o Internet Draft - DONE
o Submit to IESG for PS - JUL 03
- Update Milestone to DEC 03
- To be discussed in WG
Prefix Delegation Requirements
- Editor: Shin Miyakawa
- Status: New draft in w.g. last call
- Milestone: MAR 03
o Submit for Info
o Update Milestone to JUL 03
- To be discussed in WG
IPv6 MIBs -- TCP MIB
- Editor: Rajiv Raghunarayan
- Status: In w.g. last call
- Milestone: APR 03
o Submit for PS
o Update milestone to JUL 03
- Open Issues:
o To be discussed in WG
IPv6 Node Requirements
- Editor: John Loughney
- Status: New draft in w.g. last call
- Milestone: APR 03
o Submit for Info
o Update milestone to AUG 03
- Open Issues:
o To be discussed in WG
IPv6 MIBs -- Forwarding Table
- Editor: Brian Haberman
- Status: New draft in w.g. last call
- Milestone: MAY 03
o Re-submit for PS
- Update milestone to Aug 03
- Open Issues:
o To be discussed in WG
Node Information Queries
- Editor: Matt Crawford
- Status: New draft in w.g. last call
- Milestone: MAY 03
o Re-submit for PS
o Update milestone to Aug 03
- Open Issues:
o To be discussed in WG
IPv6 MIBs -- UDP MIB
- Editor: John Flick
- Status: Draft available after IETF
- Milestone: MAY 03
o Submit for PS
o Update milestone to SEP 03
- Open Issues:
o N/A
IPv6 MIBs -- IP MIB
- Editor: Shawn Routhier
- Status: In W.G. last call
- Milestone: JUN 03
o Submit for PS
o Update milestone to AUG 03
- Open Issues:
o To be discussed in WG
Default Router Preferences
- Editor: Rich Draves
- Status: AD Comments Received
- Milestone: JUN 03
o Submit to IESG for PS
o Update milestone to OCT 03
- Open Issues:
o Split load balancing into separate document
Link-Scoped Multicast
- Editor: Jung-Soo Park
- Status: WG Draft Available
- Milestone: JUL 03
o Submit for PS
o Update milestone to AUG 03
- Open Issues:
o Ready for WG last call?
Scoped Addressing Architecture
- Editor: Jinmei Tatuya
- Status: WG Draft Available
- Milestone: AUG 03
o Submit for PS
- Open Issues:
o To be discussed in WG
o Ready for w.g. last call?
Site-Local Limits
- Editor: (Chairs)
- Status:
o WG consensus to deprecate site-local
o Requirements and Local addressing drafts available
- Milestone: None
o Add milestones
- Open Issues:
o To be discussed in WG
Work Not Started
- ICMP Update
- Autoconfiguration Update
- Neighbor Discovery Update
- Privacy Extensions Update
- PPPv6 Update (Drop?)
- IPv6 Addressing Architecture to DS
o Add milestone NOV 03
Open Issues with IPv6 Node Requirements -- John Loughney
--------------------------------------------------------
http://www.ietf.org/internet-drafts/draf
t-ietf-ipv6-node-requirements-04.txt
(See slides)
The document is currently in last call, and needs to be updated to
address 14 issues.
Bob Hinden suggested that the Path MTU issue might be better resolved by
referencing the recommendations in the Path MTU document as it is
covered in detail there. John Loughney agreed.
Nidhi Bhaskar mentioned that SSM is in last call and that it should be
referenced in this group. She will send proposed text to the WG. Bob
Hinden raised concern that we may not want to be dependent on SSM if it is
still a draft. Brian Haberman pointed out that it is already in the
IESG, so this may not be a problem. Pekka Savola said that IPR
recently found relating to SSM, so this may not be just trivial.
Hesham asked if we should change the name of the document to host
requirements, since we aren't including router requirements. John
Loughney will work on some text for the introduction that makes this
clear, if it isn't there already. Dave Thaler pointed out that we should
have a section labeled "router requirements" unless it lists all of the
router requirements.
Alex Conta raised the issue that if neither Path MTU or
fragmentation is mandatory, you can run into problems. Dave Thaler
pointed out that RFC 2460 requires that you support
fragmentation reassembly or that you send "too big" message. This isn't in
the Path MTU document. There is a difference between what is
required for hosts and routers in this regard. Alex Conta agreed.
Rob Austein asked if there are DOCSIS devices that use MIBs but don't
support SNMP. Margaret Wasserman pointed out that DOCSIS devices do
support SNMP. Some discussion of the fact that while devices SHOULD be
manageable, SNMP is a MAY. Rob agreed that this addressed his issue.
Dave Thaler raised issue about what we do when a normative reference is
obsoleted by a newer one. Do we assume that the requirement will follow
forward to a successor? If so, we could only include references for the
currently published version. Christian suggested that we remove
references to anything that isn't published yet. Bob Hinden and John
Loughney agreed that we should review current status and decide what make
sense in each case.
Alain Durand raised concern about the fact that we might not have any
requirement for DNS discovery in the host requirements if the DNSOP WG
doesn't move forward on it. John Loughney pointed out that there is no
RFC, and no specific plan to have one. Bob Hinden pointed out that we
will need to cycle this document in the future -- if we wait for each new
thing, there will always be another one. John Loughney agreed.
Open Issues with IPv6 MIBs -- Brian Haberman
--------------------------------------------
http://www.ietf.org/internet-drafts/draf
t-ietf-ipv6-rfc2011-update-03.txt
http://www.ietf.org/internet-drafts/draf
t-ietf-ipv6-rfc2012-update-03.txt
http://www.ietf.org/internet-drafts/draf
t-ietf-ipv6-rfc2096-update-04.txt
(See slides)
No issues raised with proposed changes suggested in presentation.
Documents will be forwarded to IESG when new drafts are published.
ACTION: Submit to IESG for Proposed Standard when new MIB drafts are
published.
Open Issues with Prefix Delegation Requirements -- Shin Miyakawa
----------------------------------------
------------------------
http://www.ietf.org/internet-drafts/draf
t-ietf-ipv6-prefix-delegation-requirement-02.txt
(See slides)
Reviewed requirements.
Asked if it was ready to send to IESG.
Question raised about prefix lifetimes. Inside vs. outside prefix
lifetimes. Review minutes from previous IETF meetings. Ralph Droms
checked draft and could be added.
Margaret polled w.g. to see if we should cycle, or move ahead as is.
Consensus to not make this change. Will make editorial changes and will be
submitted to IESG when new draft is out.
ACTION: Submit to the IESG for Informational when new Prefix
Delegation Requirements draft is published.
Bridge-like Neighbor Discovery Proxies -- Dave Thaler
-----------------------------------------------------
http://www.ietf.org/internet-drafts/draf
t-thaler-ipv6-ndproxy-00.txt
(See slides)
Reviewed draft.
Few questions to clarify how it works, relationship to SEND, does it
require listening to all multicast traffic.
Erik Nordmark: Doesn't understand relationship to SEND. Not sure which
problems are being solved.
Nordmark: Loop prevention and for devices not support spanning tree
protocol. Assuming one device does spanning tree. A: Should be
possible to handle non IEEE spanning tree capable media. Q: Wants to
understand what are the limits of this proposal. Document needs to be
clearer.
Alain Durand: What happens to TTL? Answer: Nothing, bridges don't touch
TTL. Does it work with LLMNR? Answer: yes, no problem.
Question would like to see how to do SEND on Proxies. Proxy SEND is
first priority after SEND spec is done.
Margaret Wasserman: This isn't exactly prefix delegation. A: Right.
Relationship to Zeroconf Routers: A: This group not meeting this week, had
one BOF previously. No agreement on Zeroconf routers BOF. Would like to
see work go forward.
Pekka: Why is spanning tree needed, and as a consequence, we need to be
very careful which kind of problems we want to solve if we really,
really think we DO need spanning tree.
Question: Does every node see every other node. A: Yes, full
reachability to every prefix to every other prefix.
IPv6 Node Information Queries -- Bob Hinden
-------------------------------------------
http://www.ietf.org/internet-drafts/draf
t-ietf-ipngwg-icmp-name-lookups-10.txt
(See slides)
Thomas Narten asked what is implement, and there were some answers. KAME
doesn't implement IPv4 portions, but USAGI does.
Alain Durand commented on privacy handling. When someone asks for a name at a
private address, you don't want to reveal permanent names or
addresses. And, when you query a permanent address, you don't want to
return temporary names/addresses. There is also a need not to expose
mapping between private addresses that might allow you to track what the
same user is doing over time.
Rob Austein mentioned that the applicability of scenarios where these
things are relevant are out-of-scope.
Discussion of removing IPv4 address query -- at least one
implementation includes it. Alain Durand brought up question of whether we
should extend this to IPv4 transport. Bob Hinden hadn't thought about it.
Alain claims that the only thing needed to make this run over IPv4 is to
reserve the ICMP code in the IPv4 space.
A new draft is needed. Bob will propose text changes to the WG for the RFC
3041 changes. After that is resolved, could we send it to the IESG? Pekka
suggested that the applicability statement won't stop people from using
this in other ways. We should either severely limit this draft or
publish it as experimental. Alain Durand and Itojun indicated that they
would like to see the work published, because it is useful for
debugging IPv6 networks.
CONSENSUS: The group believes that we should publish something along these
lines, because of existing implementations and usefulness.
CONSENSUS: We have consensus of the group to submit the draft, with the
changes that Bob has proposed to the IESG for PS. Bob and Matt will
update the spec and circulate the changes for
discussion/approval by the WG.
IPv6 Socket API for source address selection -- Samita Chakrabarti
----------------------------------------
--------------------------
http://www.ietf.org/internet-drafts/draf
t-chakrabarti-ipv6-addrselect-api-01.txt
(See slides)
Quick overview followed by open issues, due to time constraints.
Alain Durand raised questions about whether this API would be
consistent with other APIs underway elsewhere -- IPSEC APIs, etc.
Brian Carpenter expressed a concern that this might never be used by
application programmers. They won't understand it and don't want to work on
this level. We need a different level of abstraction. Thinks we need an
API at this level, as well as at a higher level for Java
programmers, etc.
Pekka thinks that this is a good, precise API for low-level control.
Having a higher level API would be okay, too.
Jinmei Tatuya has discussed this with KAME folks -- not clear if this is the
right balance between low-level control and abstraction. Prefers
Francis Dupont's idea.
Erik thinks that some of this complexity (public/private) might be good to
expose to developers, but perhaps not others (COA optimization). Doesn't
think that per-process level stuff works well because of libraries and
assumptions made by libraries, etc.
Francis believes that this API is too low level.
Chairs asked who had read the document -- some people have.
QUESTION: Should we accept this as a WG work item? The group was split
with majority for accepting.
Thomas Narten asked why people did not want to accept. Christian
Huitema said that he does not think that we need an API at this level.
The chairs called the question again (rough count was 13 to 5 for
accepting the document). No clear consensus. We need to get more people to
read the draft and develop an informed opinion.
Link Name and Sequence Options for IPv6 Neighbor Discovery -- Naiming Shen
----------------------------------------
-----------------------------
http://www.ietf.org/internet-drafts/draf
t-shen-ipv6-nd-name-seq-options-01.txt
Deferred to Thursday morning.
Thursday, 0900-1130 (Hall F2)
=============================
Introduction and Agenda Review -- Bob Hinden
--------------------------------------------
Bob presented the agenda. There were no comments or changes.
Link Name and Sequence Options for IPv6 Neighbor Discovery -- Naiming
Shen (10 min)
----------------------------------------
-----------------------------
http://www.ietf.org/internet-drafts/draf
t-shen-ipv6-nd-name-seq-options-01.txt
(See slides)
Comments from Greg Daley. Thinks that naming portion may be
interesting. Issue regarding what happens when the sequence numbers don't
get responded to? Answer -- if you don't get a response, you send
another one.
Erik Nordmark mentioned that there is a protocol called MZAP (defined in RFC
2776) that allows this type of functionality. Dave Thaler confirmed that it
is defined for IPv6. There may be some overlap.
Bob Hinden asked w.g. if there was interest in perusing this work.
Greg Daley: Some interest in naming portion, but not in sequence
numbers.
Nordmark: Something in multicast for names as well.
Not a great deal of interest in perusing as a working group item.
Open Issues with Scoped Address Architecture -- Jinmei Tatuya
----------------------------------------
---------------------
http://www.ietf.org/internet-drafts/draf
t-ietf-ipv6-scoping-arch-00.txt
(See slides)
Major change in this version of the draft is removal of unicast
site-local addresses. No comments on the list. One issue has been
raised regarding PIM, but has been resolved and will be handled in a
separate draft. Authors believe draft is ready for w.g. last call.
Christian Huitema brought up issue of anycast addresses for service
discovery. Says that these addresses will have the same type of scoping
requirements as multicast addresses. So, he thinks that we may want to
specify a scope for anycast addresses.
Itojun responding to Christian -- wrote Anycast Analysis draft. Issue is
not about scoping, but about the propagation of an anycast route. In what
region is your anycast route advertisement propagated. Captured in
anycast analysis.
Jinmei thinks that the anycast topic is out of scope for this
document.
Tony Hain believes that this document is nowhere near ready for last call,
because it will just need to be updated in six months or less.
Margaret Wasserman believes that we should complete this draft because of
the need to get link-local addresses specified as soon as possible.
Brian Carpenter agrees that in .5 hours to six months, we will have a
local addressing architecture of some kind. He thinks that this
document needs to stay "in limbo" until we figure out what to do with
local addressing. Thinks that we need to coordinate with ABNF text
representation folks to make sure that we are in sync.
Jinmei is open to idea that we'd add local addressing to this draft, but is
pushing for last call because there are no remaining technical issues in the
contents of this draft.
Erik Nordmark indicated that he disagrees with the previous comments by
Tony and Brian. He thinks that we need to document link local. There are a
lot of open architectural issues with local addressing that he hoped there
would be answered in the IAB meeting, but they weren't. May take time to
sort out these issues.
Itojun agrees with Erik, and disagrees with Tony and Brian. We need to
publish this document as soon as possible.
Christian suggested that we finish the discussion in this meeting before we
publish this document. Margaret Wasserman pointed out that we haven't had a
last call yet. General agreement that we won't manage to issue a last call
before the end of this meeting, anyway.
Requirements for Local Addressing
---------------------------------
Local Addressing Requirements -- Tony Hain & Juha Wiljakka
----------------------------------------------------------
http://www.ietf.org/internet-drafts/draf
t-hain-ipv6-sitelocal-01.txt
http://www.ietf.org/intern
et-drafts/draft-templin-lsareqts-00.txt
(See slides)
Presentation was done by Tony, Fred and Juha in unison. Tony is
presenting, but represents shared view.
On question of local<>global communication, Dave Thaler pointed out that
there another question about whether you should be able to
communicate between to different local networks (i.e. merger case).
Margaret Wasserman pointed out that we might want to communicate
global<>local for network management and debugging, especially in
situations where you only know a local address. So, we shouldn't forbid it,
even if we discourage it.
Alain Durand pointed out that there is complexity of having local and
global addresses on the same system. Tony agreed. Alain: If you have
public PI space, would it fit all of the requirements? Tony thinks that it
would meet most of the requirements, but thinks that this should be done in
parallel with PI, because local addressing has security benefits that a
single error can't expose the whole network.
Erik was happy with terminology, but then lost him. Thinks that there
isn't a single local range -- need multiple nested and overlapping local
ranges. Tony says that this mechanism will support multiple local
ranges. Erik says that it adds to complexity to have multiple local
ranges and need to pick between them. Bob Hinden asked if this is
different from multiple addresses... Erik said that choosing between
multiple global addresses is less critical, because if you pick the wrong
one it is less efficient but works. With local addresses if the
application picks the wrong one, it may not work.
Ralph Droms pointed out that any application of scoped addressing may
cause problems with address selection. Also, heard a lot of
requirements, all followed by "and therefore we need scoped
addresses". Asked about scope of the WG -- are we chartered to work on PI
addresses? Margaret -- we need a charter update to include this work, but
the charter won't include working on a portable addressing scheme for the
Internet. That work is happening elsewhere -- IAB, multi6.
Rob Austein indicated that some of the requirements as stated miss
important intermediate steps. For example, in the case of a printer for the
SOHO market, the requirement isn't local addresses per se, it's to avoid an
unnecessary tech support load for the printer manufacturer by making it
possible for a new printer to come up out of the box able to
communicate on the local network without being accessible from the
outside world.
Brian Haberman: On question of whether we should have
global<>local communication, need to remember that
applications should not have to be aware of the scope of these
addresses. So, that may have implications for whether of not we allow
global<>local communications. Brian supports working on a combined
document, because it would be good to have one complete
requirements document in front of us, so that we could work on it.
Marc Blanchet thinks that globally-routable,
provider-independent, portable addressing is important, so we should work on
it here. Concerned that we can't work on it. Margaret agreed that this is
important, but not that it should be pursued in the IPv6 WG. Bob Hinden
pointed out that there is still a big research aspect to the question of
portable global addressing. This is very complex, and includes
conflicting requirements. Doesn't believe that this will happen soon and
that the IPv6 w.g. should not defer this work until or if a solution to
this problem is developed.
Question for the authors about combining the drafts. Are the authors in
favor? Tony and Juha (speaking for Fred who previously confirmed by
email) both indicated that they do want to do this. They were already
working on it, but didn't get it done before meeting.
Tim Chown, would like to use local addresses on networks that will be
bigger than /48. Tony: really more of a discussion for the
implementation section.
Christian Huitema -- missing requirement. You need to have different
ranges of filtering in an enterprise network. There is no such thing as a
site. Some things will be local to a division, some to a site, some to the
company, etc. The solution needs to accommodate wide ranges of
topologies. The filtering requirement cannot be met by the
addressing structure alone.
Erik Nordmark pointed out that there will be a problem if the local
addresses require apps changes, because it will take a long time to get
consensus and deploy. Pointed out that this group can identify
requirements and needs for portable addressing and send those to the IAB and
IESG. Don't have to do the work here. People think that they need an
RFC1918 replacement in IPv6 -- perhaps not a technical requirement, but
that doesn't mean it is unimportant.
Alain Durand has a problem with the logic that we need to have
requirements for local addresses, so we need to have local addresses
because they meet the requirements. Local addresses are just one
possible solution. Portable addresses are another solution. Each has
benefits and complexities. This issue needs to be explored with the
registries.
Thomas pointed out that we don't declare registry issues
out-of-scope. We need to figure out what we need and work with the
registries to do it.
Jordi Palet is concerned about NAT with IPv6. Whether or not we go with
this type of decision, we need to make it very clear that vendors must not
implement NAT in IPv6.
Asked if group is interested in seeing these documents combined, so that we
can work towards a work item in this area. Strong consensus that it would be
worthwhile to combine these documents and work forward from
here.
CONSENSUS: Combine current local addressing requirements documents and
work forward from here.
Unique Local IPv6 Unicast Addresses -- Bob Hinden
-------------------------------------------------
http://www.ietf.org/internet-drafts/draf
t-hinden-ipv6-global-local-addr-02.txt
(See slides)
James Kempf likes this proposal. But, what happens when these leak into the
Internet? Bob recommends that there should be a /7 filter to keep them
from leaking, but nothing bad happens when they leak. Not ambiguous like
site-local, so nothing bad happens.
Brian Haberman pointed out that, unlike net 10 addresses, you can tell who
has this allocation, so you can trace them back.
Itojun pointed out that you will need to run two-faced DNS to respond with
local addresses internally, but not externally. Thomas Narten
responded that that isn't necessarily true. Depending on what address
selection rules we have, this may work fine. Rob agreed with Thomas and
said that this is just like the firewall case. Itojun pointed out that he
doesn't want to see IPv6 NAT.
Marc Blanchet wanted to know if the application people have reviewed this
proposal. Marc thinks that this is a very good proposal, a "much better
site-local", but wants to know if if addresses concerns of
applications people.
Alain Durand indicated that leaking local addresses in DNS will cause
problems with delays, etc. Margaret pointed out that this may depend on
address selection rules.
Erik Nordmark indicated that there is a difference between leaking local
addresses in the DNS for nodes that _only_ have a local address, because you
can't reach them anyway. But, leaking locals for nodes that do have
globals could cause problems, especially for UDP apps.
Christian Huitema suggested changing the address selection rules to
require a better match than 7-bits to ??
Hesham indicated that we will need some type of split-DNS for these
addresses.
Tim Chown commented on several situations where having local
connections inter-connected could be complex. Bob suggested that at some
size, a network is much better off getting a sufficient number of global
addresses.
Comment that we should prefer non-global addresses in default address
selection, because they are more stable. Otherwise, you need magic in the
resolver that determines which non-global addresses are reachable.
Rob Austein pointed out that if we have to treat these specially for
address selection rules, the cost goes up. He also pointed out the need to
keep local addresses local via split DNS, because "if we are going to lie, we
should lie consistently".
Thomas mentioned that it would be good if these addresses would work with
the current address selection rules. Bob agreed, and said that we also
have the option (perhaps not a good one) of putting this in FECO::/10 for
those rules. Tony Hain pointed out that we could include something about
this in requirements document. Thomas agreed. Tony pointed out that you
may want different default selection rules in different
environments.
Comment that we need some sort of ICMP error message if the address isn't
reachable. If addresses are just black-holed an applications will keep
using it with no indication that it isn't usable.
Question on adopting as a WG document. Is it appropriate without
requirements ready?
Brian Carpenter pointed out that it is important enough to get this work
done, so we should not wait until requirements are done to accept this.
Christian agreed.
Called the question: Should we accept this as a WG work item? Strong
consensus to accept the document.
CONSENSUS: Accept "Unique Local IPv6 Unicast Addresses" as a working
group item.
Site-Local Deprecation Document Plan -- Christian Huitema
---------------------------------------------------------
(See slides)
Discussion of deprecation of FECO::/ prefix anycast addresses. Can we
still use these? These could be used as reserved global addresses,
because all sites are the same.
Erik Nordmark asked clarifying question about whether these addresses
would be used for finding local services (and be filtered at
boundaries) or for finding global services (which would require global host
routes).
Pekka Savola thinks that we should deprecate the FECO::/ anycast
addresses with the FECO::/ prefix.
Margaret Wasserman suggested that the anycast addresses in the FCOO::/
could be a replacement. Christian said that he doesn't want to argue
about solutions, just the requirement for replacements.
Dave Thaler pointed out that the real issue is the ability to
allocated hard-coded anycast addresses to reach services. Can't be
computed based on addressing, needs to be completely hard-coded.
Thomas Narten pointed out that we haven't fleshed out the anycast
architecture well enough. Some things in the v6 spec and some things in the
anycast document are at odds with each other.
Brian Carpenter would like to generalize the question. Is it a
requirement that this document says something in particular with
backwards compatibility with legacy applications using FECO::/.
Erik wants to make sure that the concern about applications needing to deal
with multiple addresses as part of this document. Christian indicated that
the specific site-local problem is not with applications handling
multiple addresses, but is specifically about applications handling
scope.
Ralph Droms think that we need to be clear about what the document is
documenting. Christian indicated that it is documenting the FECO::/10
prefix. Ralph wants to make sure that, when we come around again, we
aren't in the same place we were before we deprecated these
addresses.
Rob Austein thinks that the address selection rules should be
discussed as a source of complexity and something that should be
evaluated for future solutions.
CONSENSUS: Consensus of the group to adopt the first version
Site-Local Deprecation Document Plan document as a working group item.
---------------------------------
Meeting Adjourned
---------------------------------
|