Re: Same global address on Multiple Interface of an IP6 node
> Can a single global address (say ::) be configured on multiple > interfaces of a single ip6 node. Yes, it can. There are a few ways to accomplish this. If all the interfaces are on the same lan, then you could have a "primary" and a "backup" interface. If the interfaces are on different lans, you can run a dynamic routing protocol and advertise the address as being reachable through each physical interface on a node. In this case, the address isn't really configured on the multiple interfaces per-se (you instead have a "virtual" interface which is assigned the IP address), but the result is any interface on the node may be used. There are other methods which may be used as well. > If so is there any specific purpose for doing that ?? Redundancy. If one interface goes down, traffic will automatically switch to the another interface without disrupting existing connections. > What about link-local address, how would it be used, if single link local > address is configured on multiple interface of a same node. I'm not sure it is particularly useful. Link-local addresses are really intended to be used for bootstraping, configuration discovery, route table maintenance, and the like. Most, if not all, of these protocols work on a per-interface basis. I suppose it could allow an interface to act as a "hot standby" for another interface, automatically switching over if the primary interface fails. But this would only work if the interfaces are on the same physical lan. If they are on different lans, then the two interfaces are in different link-local scope zones and are treated as unique addresses. Roy 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]
Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt
> Not knowing the background of all readers of the doc, it might be good to > put your explicit warning in the text: > >An IPv6 node that does not include an implementation of DHCP will be >unable to obtain any IPv6 addresses aside from link-local addresses >when it is connected to a link over which it receives a router >advertisement with the 'M' flag (Managed address configuration) set >and which contains no prefixes advertised for Stateless Address >Autoconfiguration (see section 4.5.2). In this situation, the IPv6 >Node will be unable to communicate with other off-link nodes. This isn't strictly true - a node may use manually configured global or site-local IPv6 addresses and still be able to communicate with off-link nodes. Maybe the first sentence should be updated to indicate the node will not be able to dynamically obtain any IPv6 addresses, as an IPv6 may be statically assigned to a node, and the last sentence to indicate a node will require manual configuration in the absence of DHCP support when Stateless Address Autoconfiguration is not being used? Something like: An IPv6 node that does not include an implementation of DHCP will be unable to dynamically obtain any IPv6 addresses aside from link-local addresses when it is connected to a link over which it receives a router advertisement with the 'M' flag (Managed address configuration) set and which contains no prefixes advertised for Stateless Address Autoconfiguration (see section 4.5.2). In this situation, the IPv6 Node will be unable to communicate with other off-link nodes unless a global or site-local IPv6 address is manually configured. Roy 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]
RE: Proposal for site-local clean-up
> > I miss something here. How do you make sure that nodes > > configure just site local and not global address on seeing an > > RA ? Are you keeping them in separate networks i.e not mixing > > nodes that require globals and site locals ? If so, then I > > can do the same with globals with appropriate partitioning > > i.e subnet 1 - 100, is for private use only. Then the check > > is very simple. Could you clarify ? > > Same network, hearing RA's, just local policy on the restricted box to > only configure based on SL prefixes. So, instead of filtering global addresses at the firewall, you go to each individual box in the network which you want to restricted access to/from and configure it to only use restricted (i.e., site-local) addresses? And, as a bonus, you get to deal with all the complexity and problems which are introduced when using site-locals in a non-isolated environment. How, exactly, does this improve anything? Roy 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]
Questions on Configured Tunnel MTU and TOS Byte Settings
I've got a few of questions on configured tunnels, as described in draft-ietf-ngtrans-mech-v2-01.txt. - Section 3.2 discusses how to set the tunnel MTU. It covers the case where the tunnel MTU size is manually configured, with a default of 1280. While it discusses capping the tunnel MTU at 4400 when IPv4 path MTU discovery is used, it doesn't discuss a maximum configured value for the tunnel. Does this mean there is no cap when manually configuring the tunnel MTU (i.e., the configured tunnel MTU may be as large as 65515, or even larger if jumbograms are used?) - The same section does not discuss what a host should do if it receives a Router Advertisement with an MTU option. Should the MTU value received be used? If so, is there a cap associated with this MTU value? In other words, if it exceeds 4400 bytes should the value be used? - In section 3.5, the TOS byte is defined as being set to 0 unless otherwise specified. What exactly does this mean? That, if RFC 2893 is followed the DSCP in the TOS byte may be set to a non-zero value? Or that RFC 2893 and RFC 3168 should explicitly NOT be implemented for configured tunnels? If the latter, I think some discussion on exactly WHY these two RFCs are not to be implemented would be helpful. - In section 3.6, the TOS byte of the inner packet is left unmodified at the tunnel egress. This seems to contradict some of the referenced. For instance, RFC 3168 defines both limited-functionality and full-functionality support for ECN support over tunnels. For limited-functionality, which seems to most closely match what is described in this draft, it discusses what to do at the tunnel egress if the CE option is set in the outer packet header but not the inner packet header. This processing does not seem to match what is described in this draft. Is this intentional? Roy 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]
Re: Questions on Configured Tunnel MTU and TOS Byte Settings
Oops - I meant for this to go to NGTRANS and V6OPS. Roy > I've got a few of questions on configured tunnels, as described in > draft-ietf-ngtrans-mech-v2-01.txt. > > - Section 3.2 discusses how to set the tunnel MTU. It covers the case > where the tunnel MTU size is manually configured, with a default of > 1280. While it discusses capping the tunnel MTU at 4400 when IPv4 > path MTU discovery is used, it doesn't discuss a maximum configured > value for the tunnel. Does this mean there is no cap when manually > configuring the tunnel MTU (i.e., the configured tunnel MTU may be as > large as 65515, or even larger if jumbograms are used?) > > - The same section does not discuss what a host should do if it receives a > Router Advertisement with an MTU option. Should the MTU value received > be used? If so, is there a cap associated with this MTU value? In > other words, if it exceeds 4400 bytes should the value be used? > > - In section 3.5, the TOS byte is defined as being set to 0 unless > otherwise specified. What exactly does this mean? That, if RFC 2893 is > followed the DSCP in the TOS byte may be set to a non-zero value? Or > that RFC 2893 and RFC 3168 should explicitly NOT be implemented for > configured tunnels? If the latter, I think some discussion on exactly > WHY these two RFCs are not to be implemented would be helpful. > > - In section 3.6, the TOS byte of the inner packet is left unmodified at > the tunnel egress. This seems to contradict some of the referenced. > For instance, RFC 3168 defines both limited-functionality and > full-functionality support for ECN support over tunnels. For > limited-functionality, which seems to most closely match what is > described in this draft, it discusses what to do at the tunnel egress if > the CE option is set in the outer packet header but not the inner packet > header. This processing does not seem to match what is described in > this draft. Is this intentional? > > Roy 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]
Re: Default site-local behavior for routers
> This suggestion leads to the model where hosts with multiple > interfaces will assume that all its interfaces are in the > same site (e.g. have the same site-local zone id) unless > explicitly configured to have multiple sites. While routers > will default to having a unique site-local zone id for each > interface (thus rendering SLs to link-local behavior) unless > explicitly configured to have multiple interfaces in the > same site. > > This difference in behavior for hosts and routers leads to > some interesting issues. One big one is how the site-local > zone ids are setup and potentially changed when a host > becomes a router or vice versa. > > What are others' opinions on this issue? The correct default really depends on the intended use of the node. Having interfaces default to being in different site-local scope zones makes sense for specialized boxes whose purpose is to be a site boundary router, like a home gateway router which has a WAN interface and one or more LAN interfaces. For these types of specialized nodes, it probably makes sense to default the WAN interface to one site-local scope zone and the LAN interface(s) to a separate site-local scope zone. The same type of logic could be applied to nodes which act as firewalls, where the "public" interfaces are in one site-local scope zone and the "private" intranet interfaces are in a different site-local scope zone. In this case, other configuration information can be used to derive the default site-local scope zones for the firewall's interfaces. For a typical host or router, though, a better default would be to have all interfaces in the same site-local scope zone. This is more consistent with what is shipping today. Indeed, many of the routers which ship today are not capable of being configured as a site boundary router, much less default to that behavior. Keep in mind that vast majority of hosts also support IP forwarding (although it may not be enabled by default), so this effectively says these hosts must be capable of being multi-sited. And I don't think we have a good enough grasp on what the impacts are to support multi-sited hosts. Not to mention the problem Brian raises above on having different defaults based on whether a node is a host or a router - the site-local scope zone IDs will change as IP forwarding is enabled or disabled. Since the scope zone ID is part of the sockaddr structure and is needed to identify the remote partner when using non-global addresses, this could (and very well may) result in loss of connectivity for active connections. Assuming that the use of site-local addresses is not restricted to sites which are not connected to the global internet or other sites (which is my preference), what I'd like to see is this (or another) WG define exactly what support is needed to make this work. This includes standards to define what a site boundary router needs to implement, including updates to routing protocols and the forwarding logic as defined in the scoped addressing architecture. It should also include a BCP which defines application impacts associated with using site-local addresses in these environments and gives guidance on how to work around the problems. For hosts, we should indicate that the current standards only specify how a single-sited host should behave, and multi-sited host support is undefined pending possible future standards work. But lets stop trying to define the default site-local scope zone configuration for hosts and routers. If a router can act as a site boundary router, the router vendor can decide the appropriate default configuration for their product, and whether certain interfaces should be in the same site-local scope zone or in different site-local scope zones by default. Roy 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]
RE: Limiting the Use of Site-Local
> I have a basic problem with this thread. We have a few people discussing > fundamental changes in close to a vacuum. At best the result of this > discussion should be a separate BCP, but before that happens operators > of networks that actually use 1918 space need to be engaged to find out > their requirements. > > The whole idea that SL should be revoked if a global is available is > bogus. It is certainly reasonable for the manufacturer of light switches > to only support SL/LL rather than potentially multiple global prefixes. > There is no reason for those devices to interact across a scope > boundary, so the peer nodes that may also need global access MUST keep > their SL to interact in the limited scope. I thought global addresses could be used to communicate with peers using addresses of any scope as long as the interface over which the packet is sent is in the same scope zone as that peer. As such, a node with a global address does not require a site-local address to communicate with a node which has a site-local address but lacks a global address, as long as the two nodes reside within the same site. Roy 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]
Re: Node Requirements Issue 3
> > When a multi-sited implementation gets site-local addresses from > > the DNS (assuming that it runs two-faced DNS and returns site-locals), > > how will the multi-sited host know which site the addresses are in? > > My guess, and tentative implementation is that the resolver library > completes the scope id to the address using the interface from which > the DNS reply came in. You may also need to send the DNS query into each site-local scope zone in order to obtain all necessary results, or even to obtain any results, if a given host name only resolves to site-local addresses in one of the site-local scope zones. If the DNS name server is on a muti-sited host (which I suppose makes sense if it is performing name-to-address resolution for hosts which are muti-sited), then it needs to be configured to return different site-local addresses for each given site to which it is connected. Since Stateless Address Autoconfiguration or (eventually) DHCPv6 may be used to configure addresses, the DNS name server also needs to understand the site-local scope zone over which a DNS registration is made, placing "global" addresses into the "global" pool and "site-local" addresses associated with the site-local scope zone over which the registration is received. Likewise, the host performing the registration needs to restrict the site-local addresses which are registered to the site-local scope zone in which they are valid. There are probably other requirements for this to work as well. The only point I'm trying to make is it isn't just as simple as connecting to multiple sites and having this work properly without additional standards being defined. Roy 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]
RE: Node Requirements Issue 3
> How do site-locals work? > > For a single-sited host, I think the main requirement is > draft-ietf-ipv6-default-addr-select-09. For applications that send > addresses to correspondents (note this is a small minority of > applications) it can get more complicated but it's still not bad - see > kre's recent emails about this. I know MS is porting/developing such > applications but I'm not involved. I'd agree as long as the single-sited host is not connected to the global internet. When connected to the global internet, many applications will work just fine. But there are some application protocols as currently defined which do not work. It would seem useful to try to identify the classes of applications which break in these configurations and what actions need to take to occur to update the protocols and/or applications to allow this to work. Once this is understood, it would be easier to gauge whether using site-local addresses when a site is connected to the global internet is worth the effort. > For DNS, I implemented draft-ietf-ipngwg-site-prefixes-05 and it works > great. Unfortunately since that draft seems to be dead, I think the > fall-back for now is that to use site-locals you'll need a two-faced > DNS. Yes, although not pretty two-faced DNS works for single-sited hosts. > For a multi-sited host, one additional requirement is that applications > should deal with sockaddrs instead of directly with addresses, so that > the scope-id is preserved & passed around as needed. Another additional > requirement is routing table lookup needs to be cognizant of scoping. If the DNS resolver fills in the appropriate scope zone ID for site-local addresses, then the application can use the sockaddr for communication. How the scope zone ID gets filled in, and how the DNS resolver queries two-faced DNS name servers in different sites and consolidates the (now different) responses is what has not been defined. For instance, since each site would need to run two-faced DNS to allow site-locals to be placed in DNS, each may return different results for the same host. Depending on which site the DNS query is sent and how DNS is configured, the resolver may receive no addresses, only global addresses, or a mixture of global and site-local addresses. This was covered on this list previously with no agreed-upon resolution on how to make this work, not to mention any IDs with concrete proposals to be reviewed. There are, of course, additional issues for multi-sited hosts. At a minimum, there are the routing changes which have been discussed here previously, and possibly others which have yet to be identified. None of this is insurmountable. With sufficient architecture and updates to susceptible applications, support for multi-sited hosts can likely be made functional. Whether it is worth the effort is a different question, though, and one which only this WG can answer. Roy 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]
RE: Node Requirements Issue 3
> This is craziness. We (I don't mean just MS) have shipping > implementations that support site-locals. We have operational > deployments using site-locals. We have applications that work just fine > with site-locals. Could you (or someone else who has this working) publish an ID which describes how site-locals work? I've seen many postings on various aspects of site-locals which do not work as currently defined, from DNS to routing to applications using site-locals in referrals. There have been some proposals on how to address some of these issues, such as updates to dynamic routing protocols, but others (like DNS) don't seem to have any agreed upon solutions in multi-sited configurations and, arguably in the case of DNS, single-sited configurations. Without standards, or at least standards-track IDs, its hard to see how site-locals can be viewed as useful beyond a single-site configuration, with anything beyond that being experimental and/or proprietary. Roy 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]
Comments on draft-ietf-ipv6-scope-api-00.txt
While working on supporting and exploiting the scoped address architecture, I've noticed I need several new APIs to implement the support within applications and library routines. For instance, I've found that I need versions of inet_pton() and inet_ntop() which support scoped addresses. I guess one option here would be to deprecate both of these APIs and instead use getnameinfo() and getaddrinfo() to perform the function, but that just doesn't feel right when processing link-local addresses or multicast addresses. I've also found a need for APIs to map a scope zone index to a scope zone name and vice-versa, similar to how if_nametoindex() and if_indextoname() work for interface indices and names. How are others dealing with supporting scoped addresses within their applications and library routines? While I could define proprietary API extensions to support these functions (and will have to if there are no standard ones available), it seems to me that others who implement the scoped address architecture will need similar APIs. Is this something which needs addressing, and if so should the APIs be standardized? If the answers are yes, then it would seem to me the logical home would be the new scoped address API draft. Is anyone actively working to update this draft to include new scope-aware APIs? If not, and if there is interest, I'd be willing to take a stab at defining the API extensions needed to support the scoped address architecture. Roy 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]
Scoped Address Extensions to the IPv6 Basic Socket API
I was happy to see this draft, as I've been struggling to understand how applications will work in the presence of limited scope addresses. I've got a few questions and comments regarding the draft. Some of these may be more appropriate for the Scoped Address Architecture draft, especially in the areas surrounding DNS behavior (some of which has already been discussed on the mailing list). Note that most of my confusion surrounds hosts connecting to more than one site-local zone. If this support was omitted from this and the Scoped Address Architecture draft, then many of my questions below would disappear. - I don't see versions of inet_ntop() and inet_pton() which support the proposed address format for limited scope addresses. I would have thought both would be needed. Or are these APIs being deprecated in favor of using getaddrinfo() and getnameinfo() to perform this mapping (both for unicast and multicast addresses)? Either way, I think it would be good to address this within this draft. - I would like to see new APIs to map between a zone index and zone name provided, similar to the if_nametoindex() and if_indextoname() calls. At a minimum, these will be needed for the updated resolver APIs, which becomes important given many platforms port their resolver from the BIND distribution. - getaddrinfo() - What value should sin6_scope_id be set to for limited scope addresses, such as a site-local address? Should it be the scope index for the given zone into which the query is sent? If so, does a resolver need to send the same query into each zone to which it is attached? I find the whole interaction between the resolver, DNS name server, and limited scope addresses is extremely confusing. - If the host name includes a scope ID, should this restrict the zones into which the DNS query is sent? I would assume so, but have questions based on the next bullet. - If the host name includes a scope ID, but the scope ID is not valid at the invoking host, what should be done? Should the query fail? Or should the scope ID be included on the limited scope addresses returned? - If the host name includes a scope ID, but the scope ID is not valid for all the limited scope addresses which need to be returned, what should be done? For instance, if a local hosts file includes both link-local and site-local addresses, but the scope ID is only valid for the site-local addresses, what should occur? Should the call fail, or should only the site-local addresses be returned? - getnameinfo() - If NI_NUMERICSCOPE is not specified and the scope identifier cannot be mapped to a scope zone name, what should this API do? Should the call fail, or should it return the numeric form of the scope identifier? - What should be done if a nonzero scope identifier is included with a global IPv6 address? Should the call fail, or should it return the numeric form of the scope identifier? - If a nonzero scope zone index is included, should it be used to restrict the zone into which the DNS query is sent? For instance, if the address is of site-local scope, should the query only be sent into the zone which is identified by the scope ID? Or should the resolver send the query into (any? all?) zones? - For a limited scope address with a zero scope zone index, into which zones should the resolver send the query? Should it send it into the "default" zone, any zone, or send the query into zones? Since the host would send a packet using this address/zone index pair into the "default" zone, it might make sense for the resolver to do the same. - The discussions from the Scoped Address Architecture draft on when to include the scope ID in textual formats should probably be moved into this draft. For instance, the Scoped Address Architecture draft talks about omitting the zone ID for the default zone on textual displays. Roy
Re: GETNAMEINFO questions ...............
On Thursday, 11/29/2001 at 08:55 EST, Lori Napoli/Raleigh/IBM@IBMUS wrote: > draft-ietf-ipngwg-rfc2553bis-04.txt section 6.2 states: > > The flags argument is a flag that changes the default actions of the > function. By default the fully-qualified domain name (FQDN) for the host > shall be returned, but: > > - If the flag bit NI_NOFQDN is set, only the node name portion of the > FQDN shall be returned for local hosts. > > - If the flag bit NI_NUMERICHOST is set, the numeric form of the > host's address shall be returned instead of its name, under all > circumstances. > > - If the flag bit NI_NAMEREQD is set, an error shall be returned if the > host's name cannot be located. > > - If the flag bit NI_NUMERICSERV is set, the numeric form of the > service address shall be returned (for example, its port number) > instead of > its name, under all circumstances. > > - If the flag bit NI_NUMERICSCOPE is set, the numeric form of the > scope identifier shall be returned (for example, interface index) > instead of its name. This flag is ignored if the sa argument is > not an IPv6 address. > > - If the flag bit NI_DGRAM is set, this indicates that the service is > a datagram service (SOCK_DGRAM). The default behavior shall assume that > the service is a stream service (SOCK_STREAM). > > So what if NI_NUMERICHOST is not set and NI_NAMEREQD is not set. > Getnameinfo attempts to resolve the name via DNS query and scan of the > local files. If the host name is not resolved, do we return the numeric > form or an error? You should return the numeric form. The pertinent text which describes this situation appears just prior to the flags you included above. > Also, if NI_NUMERICSERV is not set, getnameinfo calls getservbyport to scan > the local service name file and if the service name is not resolved we > return the numeric form. So, how can the application calling getnameinfo > determine that the resolution of the service name failed since it can > receive the numeric form regardless of NI_NUMERICSERV setting. It would > have to determine that numeric form was returned and NI_NUMERICSERV had not > been specified. There doesn't seem to be a service name equivalent of > NI_NAMEREQD. Should getnameinfo return the numeric form of the service > name if name resolution fails or should we return an error? Again, the draft specifies that the numeric form be returned. And you seem to be correct - there isn't an equivalent to NI_NAMEREQD for the service name. I guess any application which was really interested whether the port number could be found in the service name file would need to use strcmp() to compare value returned to the value which was input, and if they are the same and NI_NUMERICSERV was not coded infer (possibly incorrectly if someone coded a numeric service name in the local file) that the name could not be located. Roy Brabson 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]
Re: IPv6 RAW packets
On Wednesday, 09/26/2001 at 12:49 AST, Lori Napoli/Raleigh/IBM@IBMUS wrote: > Just curious what other implementations are doing with RAW IPv6 packets. > When you send the packet back up to the application are you including the > IPv6 header and all the extension headers? Theoretically, an application > that is performing ICMP ECHO/ECHOREPLIES doesn't need anything in the IPv6 > header or extension header but obviously an application that is performing > Neighbor Discovery would. If you are returning the IPv6 header and > extension headers, then I imagine all the IPv6 RAW applications need to add > code to handle all the extension headers since the IPv6 header doesn't have > a field that gives the length of all the headers like IPv4. Right? A quick look at RFC2292, as well as the now-expired *bis version, indicates that neither the IPv6 header nor the extension headers are made available to applications in their raw format (i.e., as part of the packet data). Instead, the relevant information is made available using ancillary data objects. Applications can control which ancillary data objects they receive using socket options and/or ancillary data. The relevant text describing this is in Section 3 of both documents. Roy Brabson 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]
Re: Wrap up and last call: sin6_scope_id semantics
On Thursday, 08/30/2001 at 12:08 ZE9, JINMEI Tatuya / $B?@L@C#:H(B <[EMAIL PROTECTED]> wrote: > I'd like to propose the following approach: > > - the scoping architecture draft only defines the numerical zone IDs > and their aliases for readability (like "site1") This is fine. I've never really objected to the aliases, I just don't find them very useful. > - the scoping architecture draft does NOT define the zone "names", but > mentions that implementation can use intuitive names in the textual > representation, and that interface names can be used as > interface/link/subnet zone IDs by default. Good as well. Maybe something like an implementation MAY choose to display the names used in configuring the zones in the textual representation. I just don't want anyone to read the text and think this type of behavior is somehow precluded. > - write a separate informational document, which talks about the API > of the scoping issues, including possible representation of names, > and mapping of numerical identifiers and names. Yes, I think keeping the API discussion out of the standards track RFC makes sense. And I like having the informational RFC for the API issues as well. Roy Brabson 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]
Re: Wrap up and last call: sin6_scope_id semantics
On Thursday, 08/30/2001 at 02:06 ZE9, JINMEI Tatuya / $B?@L@C#:H(B <[EMAIL PROTECTED]> wrote: > > True, if two interfaces are in the same link-local zone then the interface > > name will not uniquely identify the zone. But the current scoping > > architecture draft indicates that configuration is required to identify > > that two interfaces are in the same zone, and the name used in this > > configuration can be used for display of the zone name. > > I don't see such indication of the draft...which text of the draft do > you really mean? The text is in section 6, which covers zone indicies (cut and pasted below): | There is at present no way for a node to automatically determine | which of its interfaces belong to the same zones, e.g., the same link | or the same site. In the future, protocols may be developed to | determine that information. In the absence of such protocols, an | implementation must provide a means for manual assignment and/or | reassignment of zone indices. Furthermore, to avoid the need to | perform manual configuration in most cases, an implementation should, | by default, initially assign zone indices as follows, and only as | follows: | | o A unique interface index for each interface | | o A unique link index for each interface | | o A unique subnet (multicast "scop" value 3) index for each | interface | | Then, manual configuration would be necessary only for the less | common cases of nodes with multiple interfaces to a single link or a | single subnet, interfaces to different sites, or interfaces to zones | of different (multicast-only) scopes. The diagram which follows shows, as a default, what is described above: that two interfaces on a single link are, by default, given unique link-local scope IDs. This doesn't address an automatic way to learn about a link-local or site-local zone, but then again any such mechanism can be made to include the appropriate zone name at the same time it configures the zone. > > I would prefer to use the textual representation which matches what is used > > in configuring the zones. It just makes more sense to echo back what a > > user placed in a configuration file instead of displaying an arbitrary > > value dynamically created by a given stack. How exactly would a user > > correlate an arbitrary value such as "link1" or "site5" to the given zone > > which they want to use, anyway? This would seem to be the equivalent of > > telling a user they need to "guess" the correct interface ID without > > proving if_nametoindex() to perform the translation of the configured > > interface name to the corresponding interface ID. > > I admit that "link1" is not user-friendly. But please note that the > textual representation described in the scoping architecture draft > basically defines numerical zone IDs only, which are also > "user-unfriendly". But the draft also allows implementations to > introduce more intuitive, more user-friendly format such as interface > names for links, assuming one-to-one mapping between interfaces and > links. > > Since the notion of "names" can be different among implementations, I > don't think the architecture draft should define the details of > "names". The problem with the 4+28 split model, however, is that > numerical identifiers would even annoy users (not just be > user-unfriendly), because we'd see IDs like "1342177281" (which is > 0x5001, i.e. a site ID of site index 1). So, "site1" is just a > readable alias for "1342177281", which is a different kind of notion > from "names". The textual representation is more readable, but I don't find it substantially more useful. It still doesn't help anyone understand which site or which link is being used. How does someone using a zone such as "site1" have any idea which zone the packet will be sent, or which interfaces are defined to be within that zone? The "names" used to configure zones is going to be platform-unique. I guess I'd just prefer to see the values used by and returned from the DNS resolver incorporate those names vs. something like "link1" or "site1". By default, for link-local this is the interface name. Roy Brabson 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]
Re: Wrap up and last call: sin6_scope_id semantics
On Wednesday, 08/29/2001 at 10:25 ZE9, JINMEI Tatuya / $B?@L@C#:H(B <[EMAIL PROTECTED]> wrote: > > I also prefer eth0 over link12. Using the names used to define the zones > > (either the default interface names or actual zone definitions) seems to be > > more useful than generating a somewhat arbitrary name and displaying that. > > How is the user supposed to correlate link12 back to the actual eth0 > > interface, anyway? I imagine another external or display could be used, > > but this would seem to introduce yet another step for a user to identify > > the particular interface/zone in question. > > When we can assume one-to-one mapping between interfaces and links, > that's true. However, if two (or more) different interfaces belong > to a single link, using interface names as link IDs would be rather > confusing (we'll lose the uniqueness of the ID, or we'll have to care > about which interface is "primary" in the link".) True, if two interfaces are in the same link-local zone then the interface name will not uniquely identify the zone. But the current scoping architecture draft indicates that configuration is required to identify that two interfaces are in the same zone, and the name used in this configuration can be used for display of the zone name. > As I said in a previous message, I do not necessarily object to using > "names" as an implementation dependent convention. I just would like > to stick to "link1" or "site5" in the official textual representation > in the scoping architecture draft. I would prefer to use the textual representation which matches what is used in configuring the zones. It just makes more sense to echo back what a user placed in a configuration file instead of displaying an arbitrary value dynamically created by a given stack. How exactly would a user correlate an arbitrary value such as "link1" or "site5" to the given zone which they want to use, anyway? This would seem to be the equivalent of telling a user they need to "guess" the correct interface ID without proving if_nametoindex() to perform the translation of the configured interface name to the corresponding interface ID. Roy Brabson 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]
Re: Wrap up and last call: sin6_scope_id semantics
On Monday, 08/20/2001 at 11:15 ZE2, Francis Dupont <[EMAIL PROTECTED]> wrote: > In your previous mail you wrote: > >> => I prefer real names than xxxNNN. Can we get both (i.e. a config file >> plus a default translation rule)? > >I do not object to introducing real names, but I'd like to leave that >part as implementation dependent, and just define the formal aliases >(like "link2") in the scope architecture draft. > > => I don't understand your problem there: I prefer fe80::%eth0 to > fe80::%link12, I believe you too... I also prefer eth0 over link12. Using the names used to define the zones (either the default interface names or actual zone definitions) seems to be more useful than generating a somewhat arbitrary name and displaying that. How is the user supposed to correlate link12 back to the actual eth0 interface, anyway? I imagine another external or display could be used, but this would seem to introduce yet another step for a user to identify the particular interface/zone in question. Roy Brabson 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]
Re: Wrap up and last call: sin6_scope_id semantics
On Thursday, 08/16/2001 at 03:40 ZE2, Erik Nordmark <[EMAIL PROTECTED]> wrote: > > So, the basic idea is as follows: > > > > - take 4+28 split. > > - actual mapping from zone to the 28 bit part does not matter, but it > > should not change while the node is running (as discussed in this > > thread) > > - introduce "aliases" for numeric zone IDs to improve readability in > > the textual representation. e.g. "link2" is an alias of a link ID > > whose intra-link id is 2 (i.e. 0x2002). "site4" is an alias of > > a site ID whose intra-site id is 4 (i.e. 0x5004). We now allow > > fec0::1234%site4 as well as fec0::1234%1342177284 (1342177284=0x5004) > > - when a zone ID is used with an address (typically in the sockaddr_in6 > > structure), the scope type of the ID must be equal to the scope type > > of the address. > > Seems like, to the extent that there are existing applications > which use if_nametoindex() -> sin6_scope_id for link-local addresses, > we need to also support the top 4 being zero as an alias for the > interface or link scope. > > Does anybody know of such applications? > Does anybody know of applications doing the reverse (taking sin6_scope_id > and passing it to if_indextoname())? This may work when the default link-local zones are used, but how will it work in the presence of manually-configured link-local zones? The current IPv6 Scoped Address Architecture draft allows implementations to configure multiple links to be in the same link-local zone. If this is done then there is no longer a one-to-one correlation between the link-local zone and the interface ID. It is probably useful to have a standard (or at least agreed upon) way to map between the sin6_scope_id and the zone name, something akin to the if_nametoindex() and if_indextoname() calls for converting an interface name to an index and vice-versa. While using the if_nametoindex() and if_indextoname() calls may work in some cases for link-local addresses (and maybe not even for link-local if manually configured link-local zones are used), it won't work for other scopes. Such an interface would be of use to a DNS resolver, and I can see other applications perhaps wanting to perform these types of mappings directly as well. Roy 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]
Duplicate Address Detection on a link-local address
I've got a question on Duplicate Address Detection for link-local addresses. DAD states that a node must join the solicited-node multicast group for the tentative address before beginning DAD. Multicast Listener Discovery states that as part of joining a link-scope multicast groups, other than the all-nodes group, a MLD Report message must be sent. MLD also states that the source IP address in the MLD message must be a link-local address. So, what should be put in the source address for the MLD Report when the a link-local address is being assigned and no other addresses exist for the link? Since the link-local address is tentative, it shouldn't be placed as the source address in the MLD Report. Since the MLD Report requires a link-local source IP address, an MLD Report can't be sent. I'm guessing that the correct behavior is as follows when assigning the initial link-local address to an interface: - We notify the adapter that we want to receive any packets destined for the solicited-node multicast group derived from the link-local address. We do *not* send a MLD Report at this time, though, as we do not have a non-tentative link-local address to place in the source IP address. I've been told that this might cause problems when a LAN is bridged a bridge is checking MLD messages to determine where listeners are in an effort to avoid forwarding packets when there are no listeners. - We perform Duplicate Address Detection. Since we have notified the adapter to forward multicast packets for the solicited node multicast group, we should receive any Neighbor Solicitations from other nodes performing DAD as well (assuming that bridges are forwarding multicast packets in the absence of MLD messages). - If we fail DAD, we would notify the adapter that we no longer want to receive packets destined for the solicited-node multicast group which we previously registered. If we succeed with DAD, we send an MLD Report for the solicited-node multicast group. There are some other alternatives which might make sense if bridges are keying off MLD Reports to determine whether to forward multicast packets: - When assigning a tentative link-local address and no other address exists for the router, send an MLD Report with the source address set to the unspecified address. This is currently not allowed by MLD and might result in the packet failing verification by a bridge/router and therefore being discarded. - Send the MLD report using the tentative link-local address as the source IP address. We aren't supposed to use a tentative address as the source IP address, but I don't think it will break anything in this case. If a node already owns the IP address or is itself running DAD, this would result in an extra MLD Report being sent to the bridge/router. And if the address is not currently in use and no one is performing DAD then I would need to send an MLD Report after assigning the link-local address anyway. Still, I'm not real fond of idea of sending a packet using a tentative address as the source IP address. This only applies for the first (and, for us anyway, the only) link-local address assigned to the interface. All subsequent addresses would be processed as described in the RFCs: we would join the appropriate solicited-node multicast group prior to starting DAD vs. waiting until DAD is completed. Roy 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]
Re: RFC 2553 bind semantics harms the way to AF independence
>From my reading of 2553bis, there seem to be at least two ways this can be implemented (not counting the semantic changes being proposed): - The IPv4 address space is part of (a subset of, actually) the IPv6 address space. With this approach, 0.0.0.0 can be thought of as a more specific address in the combined address space than the IPv6 unspecified address ::. If an application binds to ::, then it will receive all traffic (IPv4 and IPv6). Only if IPV6_V6ONLY is set will it not receive IPv4 traffic. A second application can bind to a specific IPv6 address (say fec0::1) and begin to receive traffic for that specific IPv6 address while all other IPv6 traffic is received by the application which bound to ::. In the same manner, a second application can bind to 0.0.0.0 and it will begin to receive all IPv4 traffic, while the IPv6 traffic continues to be received by the initial application. This happens irrespective of whether IPV6_V6ONLY is set. The basic rationale behind this is 0.0.0.0 is, when encoded in IPv6 format (:::0.0.0.0), is a more specific address than ::, much in the same way that fec0::1 was in the example above, and should be treated in the same way. - The IPv4 address space is separate from the IPv6 address space. When an application binds to ::, it is the equivalent of binding to the IPv6 unspecified address and the IPv4 equivalent, 0.0.0.0. As before, a second application can bind to a specific IPv6 address (say fec0::1) and begin to receive traffic for that specific IPv6 address while all other IPv6 traffic is received by the application which bound to ::. However, a second application can only bind to 0.0.0.0 if the first application has set IPV6_V6ONLY. This is because the first application is already (conceptually) listening on 0.0.0.0. 2553 doesn't seem to specify which is the correct behavior. We've implemented the second approach, and it sounds like several others (Jim included if I'm reading it right) have as well. Roy On Wednesday, 06/27/2001 at 12:45 AST, Jim Bound <[EMAIL PROTECTED]> wrote: > > > => you can use it with the V6ONLY stuff. > > > > yes, but on rfc2553-compliant system you cannot have both an AF_INET > > and an AF_INET6 socket listening on the same port. > > Sure you can. By using V6ONLY. Thats the point of the option. It is > just you must set it via setsocopt. > > With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23 one > using AF_INET and the other AF_INET6. > > Any IPv4 addreses entering the system will not be permitted to reach any > AF_INET6 socket. > > This permits the shared port space model. 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]
Re: getsockopt() for IPV6_HOPLIMIT
On Wednesday, 06/20/2001 at 01:54 ZE2, Francis Dupont <[EMAIL PROTECTED]> wrote: > In your previous mail you wrote: > >I actually went back and read the existing RFC2292 - probably >something I should have done originally - and I think I have >a handle on this. Based on the current RFC and the -02 draft >my interpretation is that: > >- IPV6_HOPLIMIT should not be allowed on a getsockopt() or > setsockopt() call, but instead IPV6_RECVHOPLIMIT should be > used. IPV6_HOPLIMIT can still be sent/received as ancillary data. >- IPV6_RECVHOPLIMIT should be used on setsockopt() to request > that the IPV6_HOPLIMIT be returned as ancillary data. > >Does this sound correct, or am I missing something? > > => no, IPV6_HOPLIMIT is the hop limit to use and IPV6_RECVHOPLIMIT > is a flag saying that the received hop limit must be provided to the user. > IPV6_HOPLIMIT can be sticky or ancillary, IPV6_RECVHOPLIMIT must be > sticky. I'm still unsure what to return on getsockopt() for IPV6_HOPLIMIT when the unicast and multicast hop limits are different. This can happen in two cases. First, prior to any setsockopt() for IPV6_HOPLIMIT, IPV6_UNICAST_HOPS, or IPV6_MULTICAST_HOPS. Second, a setsockopt() for IPV6_HOPLIMIT followed by a setsockopt() for either IPV6_UNICAST_HOPS or IPV6_MULTICAST_HOPS. I can see several approaches to handling this: - Fail a getsockopt() for IPV6_HOPLIMIT if the unicast hoplimit and multicast hoplimit are different. This will require that the caller issue a setsockopt() for IPV6_HOPLIMIT before they can issue a getsockopt() (that is, there is no default value for IPV6_HOPLIMIT), and will also fail a getsockopt() for IPV6_HOPLIMIT if a subsequent setsockopt() for IPV6_UNICAST_HOPS or IPV6_MULTICAST_HOPS is issued. - Always return the unicast hoplimit for a getsockopt() for IPV6_HOPLIMIT. This is a little strange when the unicast and multicast hoplimits are different, but at least it is predictable and provides a default value for IPV6_HOPLIMIT. - Some other approach which I haven't thought of. Hopefully an updated version of the draft (assuming there will be one) will spell out what the proper behavior is. I still think all of this is unnecessary, anyway. Applications can use IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for getsockopt() and setsockopt() and IPV6_HOPLIMIT for ancillary data and receive consistent and predictable results. Introducing IPV6_HOPLIMIT on getsockopt() and setsockopt() seems to provide little to no value and just seems to muddy the water. Roy Brabson 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]
Re: getsockopt() for IPV6_HOPLIMIT
I actually went back and read the existing RFC2292 - probably something I should have done originally - and I think I have a handle on this. Based on the current RFC and the -02 draft my interpretation is that: - IPV6_HOPLIMIT should not be allowed on a getsockopt() or setsockopt() call, but instead IPV6_RECVHOPLIMIT should be used. IPV6_HOPLIMIT can still be sent/received as ancillary ancillary data. - IPV6_RECVHOPLIMIT should be used on setsockopt() to request that the IPV6_HOPLIMIT be returned as ancillary data. Does this sound correct, or am I missing something? Also, I see that the current 2292bis draft has expired. Are there any plans to produce an updated version? From previous postings back in November regarding the -02 draft there appear to be some incompatible changes which are being proposed, such as changing IPV6_PATHMTU to return an ip6_mtuinfo structure instead of an int, not to mention the changes I listed above (plus several others). I'd like to have our implementation track to the ID as it progresses, but if there aren't any new drafts coming then we should be implementing to the RFC. Roy On Wednesday, 06/13/2001 at 12:24 EDT, [EMAIL PROTECTED] wrote: > I'm struggling to get my hands around the interaction between > IPV6_HOPLIMIT, IPV6_UNICAST_HOPS, and IPV6_MULTICAST_HOPS. It > seems pretty straight forward if IPV6_HOPLIMIT is specified as > ancilliary data - IPV6_HOPLIMIT overrides the current hoplimit > for that packet only. But what about when IPV6_HOPLIMIT is > set using setsockopt()? > > Using setsockopt() calls, I think the behavior would be as follows: > > Unicast Hop LimitMulticast Hop Limit > ---- >default 2551 >IPV6_HOPLIMIT=100 100 100 >IPV6_MULTICAST_HOPS=5 1005 >IPV6_UNICAST_HOPS=50 505 >IPV6_HOPLIMIT=3 33 > > The question is, what should be returned for a getsockopt() on > IPV6_HOPLIMIT when the unicast and multicast hop limits are different? > Take the default case for instance. What is the correct value to return > on the getsockopt() call, 255 or 1? And what should be returned after > setting IPV6_HOPLIMIT to 100 and following it with setting > IPV6_MULTICAST_HOPS to 5, 100 or 5? > > All of this would be *much* simpler if the advanced API only allowed > IPV6_HOPLIMIT to be specified as ancillary data and required the use of > IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for setsockopt() and > getsockopt() calls. Unfortunately, that isn't the case as 2292 allows > IPV6_HOPLIMIT to be specified as a sticky option. > > Roy Brabson 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]
getsockopt() for IPV6_HOPLIMIT
I'm struggling to get my hands around the interaction between IPV6_HOPLIMIT, IPV6_UNICAST_HOPS, and IPV6_MULTICAST_HOPS. It seems pretty straight forward if IPV6_HOPLIMIT is specified as ancilliary data - IPV6_HOPLIMIT overrides the current hoplimit for that packet only. But what about when IPV6_HOPLIMIT is set using setsockopt()? Using setsockopt() calls, I think the behavior would be as follows: Unicast Hop LimitMulticast Hop Limit ---- default 2551 IPV6_HOPLIMIT=100 100 100 IPV6_MULTICAST_HOPS=5 1005 IPV6_UNICAST_HOPS=50 505 IPV6_HOPLIMIT=3 33 The question is, what should be returned for a getsockopt() on IPV6_HOPLIMIT when the unicast and multicast hop limits are different? Take the default case for instance. What is the correct value to return on the getsockopt() call, 255 or 1? And what should be returned after setting IPV6_HOPLIMIT to 100 and following it with setting IPV6_MULTICAST_HOPS to 5, 100 or 5? All of this would be *much* simpler if the advanced API only allowed IPV6_HOPLIMIT to be specified as ancillary data and required the use of IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for setsockopt() and getsockopt() calls. Unfortunately, that isn't the case as 2292 allows IPV6_HOPLIMIT to be specified as a sticky option. Roy Brabson 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]
