Hi Jinmei,
Thank you for your detailed feedback.
A few questions about your response... I'll try to respond to the more substantive points later.
3.1.2.1 Problems for All Site-Border Nodes
Some people have commented that the same problems exist for link- local addresses, but this is not entirely true. Link-local addresses can use an existing identifier, the interface name or number, as their qualifier, while site-local addresses require the configuration of an artificial zone ID.
Technically, this is not really true since links are larger scope than interfaces.
Does anyone have an implementation today that has any special handling for multi-interface links? If you want to send a packet to a LL address, are you supposed to send it out all of the interfaces for that link, or only one of them (if so, which one)?
In general, link-local addresses will only be used for specialized purposes or on single-link networks where they can be treated exactly like global addresses.
I agree about the DNS issue.
But I, as an operator of IPv6 networks, often use ping or ssh on a router (i.e., a multi-link nodes) with disambiguating an appropriate link. Is such usage included in the "general" use?
I don't know... What are you doing this for? If you are doing it to configure and test a router, then I would say 'no', this isn't general use.
3.1.2.2 Problems for Site-Border Routers
All IPv6 routers will need to check all forwarded packets to determine if either the source or destination is link-local. If so, the packet will be discarded and an appropriate ICMP error message will be generated.
The procedure cannot be that simple. First, (again) since links are larger than interfaces, it is possible for a router to forward a packet with a link-local source or destination from an interface to another one. Even in the default configuration where there is a one-to-one mapping between links and interfaces, a router can receive a packet with a link-local destination from an interface and forward it back to the same interface.
We definitely need to discuss this "links are larger than interfaces" concept... This will probably lead to link-local addresses having more of the problems associated with site-local addresses than I originally thought.
The DNS resolver must also specify a zone ID for any site-local addresses that are included in the address list returned to the calling application. [....snip]
I'm a bit confused. Isn't this an issue only for site-border resolvers? Why is this paragraph here, not in 3.3.2.2?
Actually, all hosts will have to insert a zone ID. It will be easier to do this on single-site systems (since they only have one ID to insert), but it is needed on all systems. I could make this clearer.
For example, this mechanism would not work properly when a local caching resolver is used. In this common configuration, ...
What exactly do you mean by "a local caching resolver"? Do you mean, e.g. a BIND DNS caching server running on the same node of the resolver? If so, I don't think this is not a so common configuration.
I'll have to ask whoever sent me the text :-). I think it was Rob Austein.
Application user-interfaces will need to support the inclusion of a zone ID whenever an IP address is entered by the user,
I'm not 100% sure what "Application user-interfaces" means here. Scope-aware getaddrinfo() can provide a transparent user-interface to specify zone ID, regardless of the scope type.
Sorry, I don't understand your statement, either.
If the application has a dialogue box in which the customer can specify an IP address (instead of a host name), the UI will need to allow the user to enter a zone ID, as well. That isn't true in IPv4, but it will be needed in IPv6.
and applications will have to add a default zone ID to IP addresses when one is not provided.
This is not necessarily true, or at least an implementation dependent. In fact, implementation in fact supports the ability to set a default zone ID in the kernel, so that applications need not be scope-aware.
Do you set a default zone ID for each scope? So, there would be a default link and a default site?
4.3 Networks behind NATs
This includes IPv6 sites that are connected to the IPv4 Internet via an IPv6-to-IPv4 NAT solutions, such as NAT-PT [NATPT], as well as IPv6 sites that may be connected to an IPv6 Internet using IPv6-to-IPv6 NAT.
I don't understand the intended usage about sites using IPv6-to-IPv6 NAT. Could you be more specific please?
We don't have any plans to provide portable addresses in IPv6, so people will end-up deploying IPv6<->IPv6 NAT in order to gain address portability/ISP-independence for their internal addresses. I don't like this, but I consider it a fact of life.
When they do deploy IPv6<->IPv6 NAT, it is important to have a set of readily-identifiable non-global addresses to use behind the NAT, so that we can prefer IPv4 global addresses to local IPv6 addresses (and vice versa). I am suggesting that site-local addresses be used for this purpose.
12 Appendix A: "Limited Use" Proposal
So, the author of this document recommends that IPv6 site-local addresses be reserved for use on isolated, single-site networks or behind NATs (either IPv4-to-IPv6 or IPv6-to-IPv6 NATs).
Do you actually mean IPv6-to-IPv4 NAT (not IPv4-to-IPv6)?
I mean both NAT-PT (IPv4<->IPv6) and IPv6<->IPv6 NAT (translating internal IPv6 addresses to external IPv6 addresses).
Margaret
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
