Thanks,
Bob Hinden & Margaret Wasserman
IPv6 WG Minutes July 14 & 17, 2003 IETF57 -- Vienna, Austria =========================
CHAIRS: Bob Hinden <[EMAIL PROTECTED]>
Margaret Wasserman <[EMAIL PROTECTED]>
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
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
--------------------------------------------
(See slides)
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.
Open Issues with IPv6 Node Requirements -- John Loughney
--------------------------------------------------------
http://www.ietf.org/internet-drafts/draft-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.
???? 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.
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/draft-ietf-ipv6-rfc2011-update-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-03.txt
http://www.ietf.org/internet-drafts/draft-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/draft-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/draft-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.
Alan D: What happens to TTL? A: Nothing, bridges don't touch TTL.
LLMC? OK, 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 need spanning tree? Need to be able to handle range of
topology. Should only solve problems.
an ever 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/draft-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/draft-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/draft-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/draft-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 MSAL? that
allows this type of functionality. Dave Thaler confirmed that it is
defined for IPv6. 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/draft-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/draft-hain-ipv6-sitelocal-01.txt
http://www.ietf.org/internet-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 the requirement level is too low...
Requirement isn't local addresses, it is that we need a way for a printer
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. Thinks that this will cause problems with
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/draft-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 like 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
---------------------------------
