>>>>> On Sat, 15 Mar 2003 07:40:45 -0500,
>>>>> Margaret Wasserman <[EMAIL PROTECTED]> said:
>> 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)?
Though we've not implemented multi-interface links, I'd implemented
this function so that only one of the interfaces should be the
outgoing link for each link-local destination.
>> 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.
We use this for management purposes, especially when we have a routing
trouble. A typical case is that
- we have a point-to-point link where we only assign link-local
addresses.
- a routing trouble happens around one side of the router, and we
cannot send packets beyond the router.
- to diagnose this, we first try to ping the router using its
link-local address.
- if the router is still alive, we'll then try to log in to the router
(via ssh or telnet) using the link-local address.
I guess this is NOT a "general use" according to your reply, and it's
okay since this is a matter of wording definition in the draft. But
I'd like the draft to make what "specialized purposes" means clearer
so that the reader can easily understand the above usage is a special
case.
>> 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.
I partly agree. Unfortunately, however, the designer of this model is
Steve, who is out for a long sabbatical... Besides, please note that
even if we adopt the "links is equal to interfaces" model, the issue
raised in this section still exists as I said above.
>> 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.
Okay, btw, I actually meant "I don't think this is a so common
configuration," though you seemed to read this correctly:-)
>> 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.
That's correct. What I'm trying to say is that the dialog box can
just accept the format like "fec0::1%X", as a string, using
getaddrinfo() as a backend. Then the UI itself does not need to care
about a "zone ID". Of course, you can call this "Application
user-interfaces will need to support the inclusion of a zone ID".
>> 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?
Yes. More accurately, we allow the administrator to specify the
default zone ID for each scope.
> So, there would be a
> default link and a default site?
Again, yes. However, a node is not multi-scoped for scopes
larger than links (or subnets for multicasts) by default according to
the default configuration described in the scoping arch draft. So,
the administrator does not have to set the default site zone in the
default configuration.
>> 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.
I see your points. Then please make this clear in this section.
>> 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).
I see, so you mean "between IPv4 and IPv6", not "from IPv4 to IPv6".
Then I'd like the former notation than the latter. Also, you use a
different notation in Section 4.3:
This includes IPv6 sites that are connected to the IPv4
Internet via an IPv6-to-IPv4 NAT solutions, such as NAT-PT [NATPT],
^^^^^^^^^^^^
which is one of the source of confusion (for me). If you intend the
same mechanism (e.g. NAT-PT) both in Section 4.3 and in Section 12,
please be consistent on the notation.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
