Re: site-locals
I tend to agree with Erik on the research ship case; since the ship is a rather large and coherent entity (most likley owned by an even larger organization) it makes sense for it to have one or several globally unique prefix assignments that can be used whether/not the ship has a connection to the global Internet. But, I still havn't seen a solution proposal for ad-hoc networks of individuals that come together for arbitrary purposes and wish to form a network. For example, if Bob, Ted and Alice find themselves in a common space with no proximity to an Internet access point, they should be able to form a network and have persistent communications that survive even if an Internet access point is later encountered. But, since Bob, Ted and Alice are just private individuals, it seems unlikely that any would own a globally unique prefix - so how do they decide on a common prefix to use that supports communications even in the intermittently-connected case? I have seen at least one IEEE 802.11 product vendor that solves this problem at the MAC layer by choosing the MAC address of the first node to join the network as the I-D to use for the IBSS (i.e., the ad-hoc network "cluster"). When two nodes come together for the first time, there is some sort of tie-breaking to decide whose MAC address will be used. When multiple IBSS's merge (e.g., when John and Sue join), the I-D of one IBSS is chosen as the I-D of the merged IBSS. When, an IBSS partitions (e.g., when John and Alice leave) new I-D's are chosen. But, this all seems too dynamic of a model to adopt for choosing network-layer addresses in which stable addresses are needed both regardless of the underlying topology dynamics and without a provider-assigned prefix. How do we solve this? Fred [EMAIL PROTECTED] Erik Nordmark wrote: It is not a red herring. Input sent to me for the requirements doc: But this case is exactly the same as what I categorized as #1 in my list - isolating communication local to the site from site renumbering. The only added twist is that site renumber occurs when the site attaches and detaches from the Internet. Research ships at sea intermittently connect via INMARSAT, or when in port, the shipboard network is connected to shore via Ethernet. Looking at your resarch ship case a bit more in detail it occurs to me that even using site-locals plus globals while connected doesn't necessarily protect the local communication. The introduction of the global prefix/addresses when the ship is connected might very well trigger different address selection behaviors in the stack or in the applications. Thus it seems like the robustness provided by site-locals only apply to communication established (and addresses selected) before the global prefix is introduced. Later communication is subject to any bugs or poor interaction in the address selection domain - something that is bound to have some corner cases due to its complexity. (Note that this is a property that applies to #1 in my list that I've previously not realized.) While the effect of this probably is less than the effect of renumbering the ships network each time it attaches to the Internet, it still doesn't isolate the ships internal network from being attached to the Internet when site-locals are used as you propose. So if I were to design this ship I'd use neiether renumbering at attachment time nor site-locals. Instead I'd have the research ship get a stable prefixe (a few /64's might suffice) from the organization that runs it which are globally unique and can be used whether the ship is connected or disconnected. This completely isolates the addressing of the ship internals from whether it is connected or disconnected; the only difference is the when disconnected off-ship destinations are unreachable. When it gets connected tunnel(s) need to be established back to the research organization in order for routing to work. Such tunnels could be cobbled up today with some existing tunnel establishment mechanism, and the Nemo WG is working on an IETF standard for such tunnel establishment. So if you want internal stability you have to pay by having less efficient routing - going bidirectionally over the tunnel to "home" - no free lunch. If you believe in Mobile IPv6 route optimization you might also believe that the Nemo work can be extended to provide route optimization to/from correspondent nodes in the Internet at large (by reusing the MIPv6 approach). I personally think the utility of this remains to be proven, but if it is it would help with the routing inefficiencies caused by routing. So once again, this is not a case where I think site-locals help. Erik 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: A use for site local addresses?
Jeroen Massar wrote: Mike Saywell wrote: #2 (related) For an ad-hoc network to auto-config it needs an address range to use. It's extremely limiting to confine them to a single subnet. #3 (to be found at the root of this thread) A provider independant (i.e. no upstream ISP) network which aims to provide transit between 2 or more networks (which may or may not be public). Effectively all these three boil down to one thing: - globally unique addresses - not connected to the internet A place to register globally unique, but non-internet-connected address space would be the best place IMHO. This will take quite some effort but it is quite probably the best way to avoid problems like mergers. In the case of the cruise ship, it makes sense for the ship to "own" a globally unique prefix. But, in the pure ad-hoc case, all nodes are peers and may be drawn from completely unrelated interest groups/geographies. In this case, you need to ask: "who owns the globally unique prefix?" and "what happens if the prefix owner goes away?". (I'm perfectly happy if these questions can be answered w/o site-locals, BTW.) Fred [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]
Re: A use for site local addresses?
This is very close to the use case I referred to at the microphone during the Thursday session in San Francisco when I spoke of intermittently-connected networks. Take for example an ad-hoc/mesh network that travels together and may from time to time lose connection with the global Internet; perhaps reconnecting at a different point of attachment at some later time. While detached, the nodes in the intermittently-connected network should still be able to communicate with one another. But, when reconnecting to a different point of attachment, ongoing intra-network communications should not be impacted by monolithic renumbering events. Site-locals seem like a natural mechanism for such use cases, but if they are to be deprecated a different scheme is needed. Possibilities include having one or more nodes in the intermittently-connected network "own" a global prefix that gets injected into the global routing tables at the current point of attachment, a geo-addressing scheme such as the one referred to below, or perhaps some new scheme that is yet to be identified. IMO, use cases such as these need to be identified and addressed in whatever mechanisms are chosen as we move forward. New ideas and further discussion along these lines would probably be a good thing. Fred Templin [EMAIL PROTECTED] Mike Saywell wrote: Hi all, I've only just joined the list - I'm mailing about the proposed abandoning of site locals because I'd like to use them! Basically I'm involved in setting up a community wireless network in Southampton, UK. The wireless network itself is a fully routed mesh using private (10.13/16) addresses, the long term goal is to get ISPs to provide internet gateways which you connect to via a VPN, PPPoE or some other method, over which you get a public address. We'd like to start running v6 on the network alongside the 10.13 addresses and site-locals seem like the most sensible choice since it's the only allocation of v6 addresses which is going to be available for us to use and which is large enough to accomodate a /48 per access point (of which there could be hundreds). Obviously the same internet access model could be used so you would get a public prefix over the PPPoE connection. The site-local addresses would only be used for traffic contained within the the wireless mesh, if some areas offered open internet access then they could advertise an additional prefix routed from their own internet connection, thus avoiding any NAT. Well, that's my use and case for Site-Locals in a nut-shell! I realise that this type of deployment is quite a rare case, but I think it represents a legitimate use of private addresses. By the way, another option which would work very well in this type of scenario is the geographical based addressing - http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt Thanks, Mike Saywell Southampton Open Wireless Network http://www.sown.org.uk PhD Student, Dept ECS, Southampton UK. 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] 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: dual stack & IPv6 on by default
I'm just dropping into this thread, and maybe this idea has already come up. But, when the DNS returns both A and records for a destination and when there is no v6 route, why can't the source just do automatic v6-in-v4 tunneling using an address from an record as the v6dst and an address from an A record as the v4dst? Gives you a decision tree of sorts, i.e.: 1) when an record and a v6 route exist, use native v6. Else: 2) when both and A records exist, but no v6 route, use automatic v6-in-v4 tunneling. Else: 3) when an A record exists, use v4. Else: 4) destination unreachable Fred [EMAIL PROTECTED] Erik Nordmark wrote: That's a really good question. I'm not sure what would be the best way to address this. What we're saying in this draft is that operational experience has shown that this part of ND could be problematic in some circumstances. Does ND need to be changed as a result? Probably not. There are no MUST's surrounding that bit of ND. As implementors, we're free to interpret the spec in a sane mannor. With this draft, we're pointing out reasons why implementors may want to be careful with that part of ND. There is informational value in this alone without having to muck with the ND spec itself. A possible way to approach this problem would be to make the choice between A and be a function of whether there is one or more IPv6 route off-link (or at least one IPv6 router sending RAs). That way you don't have to tweak ND. But you do end up with some having e.g. getaddrinfo() check with the kernel. I think getaddrinfo() needs to already do some checks in order to implement the default address selection document. If you don't have a route to the destination, why try to reach it on-link just in case the destination might happen to be on-link? Is there a situation where this would be useful? If you have two nodes communicating on a link and the router dies for long enough time it seems useful to be able to continue to communicate. Of course, the communication will fail once the addresses become invalid but that might take a long time. Erik 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] 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: draft-ietf-ipv6-node-requirements-03.txt
Mika Liljeberg wrote: On Thu, 2003-03-13 at 21:09, Ralph Droms wrote: Your question does raise an interesting issue - where, in the IPv6 specifications, is the behavior of a router in response to received router advertisements specified? How does a router behave if it receives an RA with either or both of the 'M' and 'O' bits set? RFC2462 states several times that routers are not expected to process router advertisements. RFC 2461, section 6.2.7 clearly does allow for routers processing router advertisements, i.e., for consistency verification. It concludes by saying: "Any other action on reception of Router Advertisement messages by a router is beyond the scope of this document." RFC 2462, section 4 says: "The remaining autoconfiguration steps are performed only by hosts; the (auto)configuration of routers is beyond the scope of this document." So, it doesn't appear to me that either specification covers the case in question. Fred Templin [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]
Re: [Draft] The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header
Hello Daniel, It is an interesting draft, but I'm afraid you've re-created RFC 1063 (albeit using IPv6 constructs). RFC 1063 was obsoleted by RFC 1191 at least partly due to the requirement that all nodes implement the protocol in order for any useful path MTU information to be obtained on a consistent basis - a feature shared by your proposal. RFC 1063 suggested two methods for implementing such a scheme - Transport Discovery and IP discovery - and it appears you have taken the low road. But, I have seen some evidence lately that an efficient packetization layer MTU discovery mechanism can be realized with no requirement for feedback from the network and no requirement for an explicit probe response from the destination. That said, your draft does give me an idea. An issue for the packetization layer scheme is to provide the lower layers with some way of knowing when a probe is in progress, i.e., so that the lower layers can let the probe through. If the packetization layer were to insert a hop-by-hop (or destination) option that essentially amounted to a no-op, the lower layers could know that a probe was in progress. Your thoughts? Fred Templin [EMAIL PROTECTED] Soohong Daniel Park wrote: Dear folks. I'd like to discuss this draft "The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header", it's not submitted yet. Before I propose, I want to listen some comments and opinion from IPv6 folks. I'll attack this draft. Please look into and response. Daniel 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
Thomas et al, The main message I am getting is that the "L" bit is a don't-care from the standpoint of RFC 2462 section 5.5, and I agree that that point needs no further clarification. But, I'm still a bit uncertain on the following point: Thomas Narten wrote: This question applies to any address a node autoconfigures, regardless of the setting of the L-bit. The scope of the advertisement of course applies to the interface on which it receives. When you say that the scope of the advertisement applies to the interface on which it receives, are you also implying that the scope of any addresses autoconfigured from prefixes received in the advertisement apply to the interface as well - regardless of the state of the "L" bit? Asked another way, when a prefix option has the "A" bit set and the "L" bit NOT set, should the address autoconfigured from the prefix be: a) assigned to the receiving interface, b) treated as a node_ID independent of any of the node's interfaces, or c) implementor's-choice? Thanks, Fred Templin [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]
Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt
Tim, Tim Hartrick wrote: Sure, that is what assigning an address to an interface means. Are you saying that you want to send datagrams that are destined to an address which is assigned to a local interface, to a router, just because the advertised prefix from which the address was derived had the "L" bit clear? No; I'm not saying that. I don't see any ambiguity in accepting the /128 resulting from address autoconfiguration as being "on-node"; i.e., it seems clear enough that packets sent by the node to the autoconfigured address should be looped back internally and not sent to a router. But, I still see it as ambiguous as to whether the /128 must be "on-link" with the interface the RA arrived on. Thanks, Fred [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]
Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt
Tim,
Tim Hartrick wrote:
Fred,
I have myself been confused by the L bit in the past but I don't think
there is anywhere near as much ambiguity here as you. And, if there is
the node requirements document isn't the place to fix it.
>
I'm still of the opinion that some ambiguity exists. Namely, if a prefix
option has the Autonomous flag ("A" bit) set and the on-link flag ("L" bit)
NOT set, one could infer from reading RFC 2462, section 5.5 that it is OK
to go ahead and configure an address from the (off-link) prefix as specified
in 5.5.3 d). But then, which link would one derive an interface identifier
from in order to form an address? (And, which interface would one assign
the address to?)
It is correct to infer that one should configure an address from a prefix
option with the A bit set and the L bit clear. Is it really necessary to
spell out that the address should be configured on the interface on which
the advertisement was received? What would justify making any other choice?
Right now, all RFC 2462 (section 5.3.3) says is to go ahead and configure
addresses for prefix options with the "A" bit set; the "L" bit is don't-care.
But, RFC 2461 (section 6.3.4) says that "a prefix information option with the
on-link flag set to zero conveys no information concerning on-link determination",
i.e., you can't tell whether the prefix is on/off link. But, if you configure an
address from a prefix option with the "L" bit set to zero and assign it to the
interface the RA arrived on, you are in effect declaring that at least one /128
chunk of the prefix is on-link. But, I don't see any text in RFC 2461 that says
you can assume this. This is where I see the ambiguity.
Fred
[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]
Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt
Thomas,
I'm still of the opinion that some ambiguity exists. Namely, if a prefix
option has the Autonomous flag ("A" bit) set and the on-link flag ("L" bit)
NOT set, one could infer from reading RFC 2462, section 5.5 that it is OK
to go ahead and configure an address from the (off-link) prefix as specified
in 5.5.3 d). But then, which link would one derive an interface identifier
from in order to form an address? (And, which interface would one assign
the address to?)
I believe this should be clarified somewere, e.g., in the IPv6 node reqt's
document. The challenge is in specifying something that is neither too
precise that it precludes legitimate functionality nor too broad that
it opens the door to security holes and/or misconfigurations. In particular,
if it's not OK for a node to configure an address from an advertised prefix
with the "L" bit not set we should probably say so somewhere and give some
rationale.
Regards,
Fred
[EMAIL PROTECTED]
Thomas Narten wrote:
"Fred L. Templin" <[EMAIL PROTECTED]> writes:
I wonder if the setting of the "L" bit in Prefix Information options
also bears some mention in this section. RFC 2461, section 4.6.2 says:
"When (the L bit is) not set, the advertisment makes no statement
about on-link or off-link properties of the prefix. For instance,
the prefix might be used for address configuration with some of
the addresses belonging to the prefix being on-link and others
being off-link."
Does this mean that prefix information options with the L bit not
set can be used to auto-configure off-link global or site-local
addresses?
No. The wording really does says what it is supposed to say. If the L
bit is is not set, one cannot say anything about whether the prefix is
on-link or off link. Specifically, a sender cannot assume that other
addresses covered by that prefix are on-link and send packets directly
to them; instead, packets for those destinations must be sent to a
router.
But it may (or may not) be the case that the destination is on the
same link as the original sender. If it is, the router will forward
the packet back to the same link. It may (or it may not) also send a
redirect to the sending node.
This is a feature that allows a router to arrange to have all traffic
forwarded to it, even for destinations that are directly reachable.
It also (possibly) helps support things like multi-link subnets, where
some destinations may be on one link, but others on a different link,
but both covered by the same prefix.
Do you have some suggestion of text to add?
Unfortunately no, because RFCs 2461 and 2462 are both ambiguous on
the subject. RFC 2461, section 6.3.4 ("Processing Received Router
Advertisements") says:
Prefixes with the on-link flag set to zero would normally have the
autonomous flag set and be used by [ADDRCONF].
But, [ADDRCONF] (i.e., RFC 2462) says nothing about how to handle
prefix options with the on-link flag ("L") set to zero!
The point is that if the bit is set, one assumes all destinations
covered by the prefix are on link. If it is not set, you can't assume
that and one does nothing.
I believe the Node Requirements document is the right place to resolve
the ambiguity; I'm just not sure what that resolution should be.
Does the above explanation help? I.e., do you still believe there is
an ambiguity?
Thomas
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
John,
[EMAIL PROTECTED] wrote:
Hi Fred,
I wonder if the setting of the "L" bit in Prefix Information options
also bears some mention in this section. RFC 2461, section 4.6.2 says:
"When (the L bit is) not set, the advertisment makes no statement
about on-link or off-link properties of the prefix. For instance,
the prefix might be used for address configuration with some of
the addresses belonging to the prefix being on-link and others
being off-link."
Does this mean that prefix information options with the L bit not
set can be used to auto-configure off-link global or site-local
addresses?
Do you have some suggestion of text to add?
Unfortunately no, because RFCs 2461 and 2462 are both ambiguous on
the subject. RFC 2461, section 6.3.4 ("Processing Received Router
Advertisements") says:
Prefixes with the on-link flag set to zero would normally have the
autonomous flag set and be used by [ADDRCONF].
But, [ADDRCONF] (i.e., RFC 2462) says nothing about how to handle
prefix options with the on-link flag ("L") set to zero!
I believe the Node Requirements document is the right place to resolve
the ambiguity; I'm just not sure what that resolution should be.
Fred
[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]
Re: Reason for the explicit link-layer address options in ND?
Francis Dupont wrote: In your previous mail you wrote: Is this just a layering question, an attempt to avoid layer violations? Or were there behind other goals, like allowing proxy ND? => both reasons. In the same kind of design ideas, it is forbidden to mix unicast and multicast between layers, i.e., if the IPv6 destination is unicast, the link-layer destination MUST be unicast, and same with multicast in place of unicast. Can you point me to the text that forbids this? I was under the impression that multicast emulation mechanisms (e.g. MARS, etc.) use unicast link-layer destination addresses when the IPv6 destination is multicast. The whole point of multicast emulation is to propagate network-layer multicasts over unicast-only link layers - not true? Thanks, Fred [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]
Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt
Roy et al, I wonder if the setting of the "L" bit in Prefix Information options also bears some mention in this section. RFC 2461, section 4.6.2 says: "When (the L bit is) not set, the advertisment makes no statement about on-link or off-link properties of the prefix. For instance, the prefix might be used for address configuration with some of the addresses belonging to the prefix being on-link and others being off-link." Does this mean that prefix information options with the L bit not set can be used to auto-configure off-link global or site-local addresses? Thanks, Fred Templin [EMAIL PROTECTED] Roy Brabson wrote: 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] 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: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt
Alain Durand wrote: Pekka Savola wrote: 3.0 IANA Considerations The following prefix is reserved for use in documentation and MUST NOT be assigned to any operational IPv6 nodes: 2000:0001::/32 ==> I do not understand why this reservation has been made; I see zero technical reason for it -- and it would prevent the use of the full 2000::/16 for something else. I disagree. Having the reserved prefix is a good think and will hopefully prevent what happen when Sun folks started documenting examples using our address space. I will agree with Alain that a reserved prefix for documentation is good. But, I don't understand why '2000:0001::/32" was chosen instead of '2000:::/32'. Can someone speak to this? Fred [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]
Re: Enforcing unreachability of site local addresses
Michel Py wrote: Fred, Fred L. Templin Your statements seem to be focused on the solutions we have at hand today along with the unspoken assumptions we have held as truths in the past. I used to think that carefully managed hierarchical routing was the only way to go to achieve scalability, but I am no longer wed to that assumption. Can you explain the reasons of the divorce? I'd prefer to think of it as an amicable parting, i.e., still on speaking terms but entertaining other possibilities. > What new stuff do you have on the front of making PI scalable? Stuff that steers routing decisions toward a unique node/site/domain/cluster/etc., I would hope. I don't think anyone is "gambling" on new and different solutions Unless you have some realistically deployable answers to the question, calling for PI now is a gamble that we will find a way to clean it or leave behind a mess 10 times bigger than the v4 swamp. In a different message, Brian characterized the NIMROD effort as a failure. But, I wonder whether similar alternatives might be viable. (Notice I'm only wondering here; not gambling...) Fred [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]
Re: Enforcing unreachability of site local addresses
Michel Py wrote: Margaret, Michel Py wrote: PI = Does *NOT* scale. Do you base this statement on hard evidence or conventional wisdom? Brian Carpenter wrote: But the problem remains as hard as it was in 1992. We don't know how to aggregate routes for such addresses, and we don't know how to scale the routing system without aggregation. Solve either of those problems and you're done. Exactly. Margaret, you are gambling on the fact that we will find a solution to a problem that we have been working on for the last 11 years and remains unsolved. PI does not scale. As of today, the closest thing we have is ID/LOC and aggregating the locators. Your statements seem to be focused on the solutions we have at hand today along with the unspoken assumptions we have held as truths in the past. I used to think that carefully-managed hierarchical routing was the only way to go to achieve scalability, but I am no longer wed to that assumption. I don't think anyone is "gambling" on new and different solutions, but I do believe we should keep the door open to them. Fred Templin [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]
Re: comments on draft-hinden-ipv6-global-site-local-00
Brian, Brian E Carpenter wrote: Pekka Savola wrote: On Thu, 23 Jan 2003, Brian E Carpenter wrote: Substantial: This document proposes an approach to allocating IPv6 Site-Local address so they are globally unique and routable only inside of a site. ==> it would be good to go a bit more in depth to how this is actually a problem. For some it surely isn't; if they don't need to prepare for site-mergers, for example. Can you define the class of sites that absolutely, definitely, until the end of time, are guaranteed not to merge? Well, it depends on quite a bit about which is the usage model for site-locals. For example, home nets probably don't merge if we would mandate that site-locals should not cross home-to-office VPN's. Let me be provocative. With proper e2e security, VPNs will become historic. And one of the benefits of IPv6 is supposd to be proper e2e security, as a result of having proper e2e addressing. But of course, there can be not absolute guarantee. Yes. Scenario: Mum and Dad share a LAN. One day they discover that young Johnny has set up his own LAN in his bedroom. They connect them together, and both of them have printers on FEC0::0002. Forgetting for the moment that the LANs in your example are probably "flat" topologies and could instead be using link-local addresses, how do you propose to prevent such duplicate assignments when disconnected/intermittently connected sites merge? Use global addresses always? If so, how can the global allocations be procured and/or maintained when the sites rarely (if ever) connect to the global Internet? Thanks, Fred [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]
Re: Change in path-MTU ..
I believe the text you are referring to is the following: "When the application is sending packets too big for the path MTU recvmsg() will return zero (indicating no data) but there will be a cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will indicate that cmsg_data is sizeof(struct ip6_mtuinfo) bytes long." The way I read this, applications are informed of path MTU restrictions when they are actively sending packets that result in ICMPv6 "packet too big" error messages (i.e., even when the "packet too big" messages are locally-generated). I see no requirement in this specification for asynchronous notification of PMTU decreases. Instead, in RFC 1918, section 5.2, I see: Note: An implementation can avoid the use of an asynchronous notification mechanism for PMTU decreases by postponing notification until the next attempt to send a packet larger than the PMTU estimate. In this approach, when an attempt is made to SEND a packet that is larger than the PMTU estimate, the SEND function should fail and return a suitable error indication. This approach may be more suitable to a connectionless packetization layer (such as one using UDP), which (in some implementations) may be hard to "notify" from the ICMP layer. In this case, the normal timeout-based retransmission mechanisms would be used to recover from the dropped packets. Fred Templin [EMAIL PROTECTED] Lilian Fernandes wrote: Section 11.3 of draft-ietf-ipngwg-rfc2292bis-08 describes a socket option IPV6_RECVPATHMTU that a UDP application can set to be notified of path MTU changes. http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-08.txt -Lilian On Tue, 7 Jan 2003, Shashi Kumar wrote: ICMP layer should recalculate the path-MTU depending on ICMP redirect and update the routing entries appropriately and also inform packetization layer(s) about the change in path-MTU ( you can have your own algo.) -Shashi Keshava Ayanur wrote: Hi, I have a question about PATH-MTU . Should the IP stack inform the application about the change in path-MTU . Else how does the application running on UDP will know about change in the size ? Or is it up to the application running on UDP to care by some reliable mechanism ? Regards, keshava 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] 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] _ Lilian Fernandes AIX TCP/IP Development - IBM Austin Tel: 512-838-7966 Fax: 512-838-3509 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] 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: DAD scope ??
Brian Haberman wrote: > Each ipv6-over-foo doc discusses modifications to ND, > if necessary, for the particular link technology. Can you point me to any text in the core architecture documents (e.g., RFCs 2461, 2462) that allow this and can be used as normative reference? Thanks, Fred Templin [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]
Re: DAD scope ??
Margaret/others, Margaret Wasserman wrote: DAD is a link-local mechanism (uses link-local multicast packets). So, while it checks all addresses, it only explicitly checks for duplicate addresses on the local link. What about DAD for links that are unicast-only? Alternatives I can imagine are: 1. specify some sort of unicast mechanism for DAD 2. perform some sort of multicast emulation (e.g., MARS) 3. avoid DAD alltogether when one can assume that addresses are uniquely assigned within the site Thoughts? Fred Templin [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]
Re: Scoping Scoped Addresses
Rich, > I do not advocate requiring every host and router implementation to have > multi-site support. I think all that's required for host implementations > is the default address selection rules, and all that's required for > router implementations is to have two modes (either all interfaces are > in the same site so site-locals are treated like globals, or all > interfaces are in different sites so site-locals are filtered). This is > really very little burden for host and router implementations. Sounds like you're referring here to the case of multilink subnets, as in Dave and Christian's draft. Having multiple interfaces attached to the same site vs. one interface per site is a design consideration we were investigating for MANET applications at SRI shortly prior to my departure 6mos ago, but we didn't come to any firm conclusions. I have been unable to find time to review that draft recently (let's just say I've been off chasing wild geese), but I'm planning to take a look at it today with two design points in mind: - does it scale to 10,000+ nodes? 100,000+ nodes? etc? - does it truly make life easier than multi-homing? Thanks, Fred Templin [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]
Re: My conclusion re site-local clean-up
Michel Py wrote: >>Fred L. Templin wrote I'd like to propose F000:/4 Wow this is big. Not to mention the difficulties of obtaining a prefix that short, I think this size would be a good fit for global PI addresses such as Tony Hain's proposal, but why would site-locals need that much? Michael, I've reflected very deeply on this and yes - I really would like to see such a short prefix set aside for other-than unicast/multicast purposes (notice I'm not saying site-locals exclusively here). As can be told from my earlier messages, I am keenly interested in large network operations in disconnected and/or intermittently connected situations. When connected to the Internet, global prefixes provide a topological frame of reference. When disconnected, no topological reference is available, but a geographical one is - it is called the Global Positioning System (GPS). To be honest, I have not read Tony's global PI proposal yet, but the DARPA mobile networking research community has been looking for ways to make geographic routing and addressing work for years. The DARPA GloMo program did some interesting work with georouting, and the ONR unmanned aerial vehicle program (along with others) have been working on a flexibile addressing scheme with geographical addressing as a core element. A limiting factor up to now has been getting enough bits for fine-grained geographic referenceing. If enough bits were available, geo-referenced prefixes would provide a nice means for supporting geographically-centered communications *with or without* the presence of global prefixes. Examples: - community networks - find the nearest Starbucks coffee by queriyng a geo-centered network - have your vehicle talk to other vehicles in the nearby vicinity w/o needing an internet access point - etc. So, I'd ask for a ::/3 or even a ::/2 if I thought there was any chance of getting it. Fred Templin [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]
Re: My conclusion re site-local clean-up
There have been some alternate wording suggestions since Brian's original message, but I like his text the best of all I've seen and vote to adopt it as it stands. We still have the use case of large networks that may have only intermittent connectivity to the global Internet that will need a stable prefix, as Brian says. But due to scaling limitations, a flat addressing space simply won't suffice - there needs to be some intra-site routing based on the stable prefixes. Finally, we have to account for cases that can occur due to mobility: 1) A large mobile network travels together from one attachment point to the internet to another 2) individual nodes or clusters in a non-attached network travel to a different location within the same non-attached network 3) individual nodes or clusters from one non-attached network travel to a differenet non-attached network The mobile ad-hoc network case (at least) is going to require routing based on stable prefixes on networks with only intermittent attachment. If there are problems with the apps, as Keith suggests, we're just going to have to fix them. I'm willing to help in any way I can. Fred Templin [EMAIL PROTECTED] Brian E Carpenter wrote: Well, that was fun: send one message and receive a few hundred. Peace. I'm very sensitive to the argument about intermittently connected networks needing a stable prefix. So I would finally prefer the addressing architecture to contain yet another version of the text in question: Site-local addresses are designed to be used for addressing inside of a site which is not permanently connected to the Internet. Using site-local addresses, a subnet ID may be up to 54-bits long, but it is recommended to use at most 16-bit subnet IDs, for convenience of subnet management. Why? Because we don't have consensus, and this text carries less baggage than the others, which seems appropriate for an architecture document. However, it may be that this change is not enough for the WG to recall the draft from the RFC Editor. I think we should hum on that in Atlanta. Brian 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: My conclusion re site-local clean-up
Margaret Wasserman wrote: I also recommend that a range of IP numbers be reserved for use as site-local addresses. This will prevent the rogue network administrator from picking addresses from the air. This range would be non-routable outside the local site. Are you talking about a range other than FECO::/10? I'd like to propose F000:/4 Fred Templin [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]
Re: Summary Re: Proposal for site-local clean-up
Margaret Wasserman wrote: How often do you think that people really set-up a private, disconnected network and later connect it to the Internet? Do you think this will be a common real-life case, or is this more of a theoretical edge case? Here again is the case for mobile ad-hoc networks. By definition, MANETs are designed to operate in infrastructureless environments. One case might be a string of vehicles on a remote highway that still find useful benefit in chit-chatting with one another even though none have access to the global Internet. But, when the string approaches a population center, hot-spot access point, etc. all should be able to share the global Internet access as long as one or more have direct connectivity. IPv6 is about anticipating and designing for *future* use cases as well as the existing paradigms of today, right? I'm *not* suggesting that we drop back into "research-mode" - only that we keep our sights set forward while we address the existing deployment scenarios we have today. Fred [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]
Re: Proposal for site-local clean-up
Tim Chown wrote: Hi Fred, That's interesting. There has been some talk about multiple ISATAP site routers, and scalability. Can you comment on how ISATAP performed in this network of thousands of (mobile) hosts? I don't have any scaling figures from actual experiments, but scaling is bounded by the frequency of the polling interval for router advertisements. The spec currently lists 15min as the recommended minimum, so a density of 900 nodes per ISATAP router would produce 1 RS/RA exchange per second. Additional overhead is incurred for nodes that are actiively using the router to carry traffic vis-a-vis NS/NA exchanges, but that overhead is the same as for peer-peer communications between nodes. If a generalized path MTU discovery mechanism were deployed, there would be still more overhead for the tunnel encapsulator and decapsulator to police the path MTU of the tunnel. But, I strongly believe that generalized path MTU discovery is *not a good thing* for wireless networks. Reason being - large packets on a lossy media (e.g., IEEE 802.11) incur increased exposure to bit error rates, probability of loss, delay variance, etc. So, there is no good reason to incur the extra overhead for generalized path MTU discovery on such media - this also saves state in the routers. (I assume you meant hundreds or thousands, not hundreds of thousands) In a single cluster - hundreds or thousands. In a large MANET with clustering - hundreds OF thousands or more. You also need to get into analysis of the relative density/sparseness of each cluster. For example, having hundreds of thousands of nodes show up in the same cluster at the same point of time might cause trouble! (But, in this case, the wireless media itself would become congested long before the ISATAP routers.) Fred Templin [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]
Re: Proposal for site-local clean-up
Keith Moore wrote: Finally, the team as a whole is only intermittently connected to the global Internet - perhaps with long periods of disconnected operation. yes, intermittent connection is one of the genuinely valid justifications for SLs. Glad to hear you agree. however even with intermittent connection it is often possible to use globals rather than SLs. the exception is a nomadic network that connects to the net at different locations at different times, and whose hosts don't have home agent(s) for mobile IP. This is exactly the case my message describe, modulo your point "whose hosts don't have home agent(s) for mobile IP", which I don't see as being relevant. In the case I described, two models are possible: 1) The node's "home" is the MANET itself 2) The node has a distant home and is always a visitor in whichever MANET it is currently in Either way, when associated with a MANET that is currently disconnected from the global Internet, site-locals seem like a nice feature. Fred [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]
Re: Proposal for site-local clean-up
FWIW, This study, along with others in the US Army CECOM division, produced the transition mechansim now known as ISATAP. Fred Templin [EMAIL PROTECTED] Fred L. Templin wrote: So much traffic has flown by on this subject that my head is still spinning. But, let me give one example in which the use of site-locals on globally connected networks might be useful. While at SRI International, I had the privilege of participating in a study of autonomous teams of unmanned vehciles with the Office of Naval Research. Such teams may consist of hundreds/thousands of mobile vehicles that travel together in a more-or-less coordinated fashion. Communications are nicely modeled by Mobile Ad-hoc Networking, as in the IETF MANET WG. Very large teams may be organized into "clusters" based on geography, commonalities of interest, etc. Finally, the team as a whole is only intermittently connected to the global Internet - perhaps with long periods of disconnected operation. When the team is out of contact with the global Internet, site-locals can provide a nice means to facilitate intra-cluster and inter-cluster communcations. When the team comes in contact with an access router(s) to the the global Internet, the global prefixes can be disemminated to team members that need global access. But since the team is mobile, global access may be intermittent, with new global prefixes learned as different access routers are encountered. So it seems tome that site-locals can provide a useful mechanism for large mobile networks with intermittent global connectivity. Fred Templin [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] 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
So much traffic has flown by on this subject that my head is still spinning. But, let me give one example in which the use of site-locals on globally connected networks might be useful. While at SRI International, I had the privilege of participating in a study of autonomous teams of unmanned vehciles with the Office of Naval Research. Such teams may consist of hundreds/thousands of mobile vehicles that travel together in a more-or-less coordinated fashion. Communications are nicely modeled by Mobile Ad-hoc Networking, as in the IETF MANET WG. Very large teams may be organized into "clusters" based on geography, commonalities of interest, etc. Finally, the team as a whole is only intermittently connected to the global Internet - perhaps with long periods of disconnected operation. When the team is out of contact with the global Internet, site-locals can provide a nice means to facilitate intra-cluster and inter-cluster communcations. When the team comes in contact with an access router(s) to the the global Internet, the global prefixes can be disemminated to team members that need global access. But since the team is mobile, global access may be intermittent, with new global prefixes learned as different access routers are encountered. So it seems tome that site-locals can provide a useful mechanism for large mobile networks with intermittent global connectivity. Fred Templin [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]
New mailing list for MTU discussions
FYI, This seems relevant to IPNG interests also (cross-posting from v6ops/ngtrans): Fred Templin [EMAIL PROTECTED] Fred L. Templin wrote: > FYI, > > Below is a message from Matt Mathis (fwd'd with his permission) announcing > a new mailing list for MTU discussions. Matt has also posted an interesting > new document titled: "Path MSS Discovery". See: > > http://www.psc.edu/~mathis/MTU/draft-mathis-MSS-discovery.txt > > Fred Templin > [EMAIL PROTECTED] > > > Date: Thu, 7 Nov 2002 15:49:05 -0500 (EST) > > From: Matt Mathis <[EMAIL PROTECTED]> > > Subject: Please subscribe to a new MTU mailling list (fwd) > > Message-ID: <[EMAIL PROTECTED]> > > MIME-Version: 1.0 > > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Content-Length: 666 > > > > For all *technical* and *public policy* issues pertaining to pushing > up the > > Internet MTU. This is an open list, so please be careful. You > must be > > subscribed to post. > > > > See http://www.psc.edu/~mathis/MTU for more information > > > > If you are interested, please subscribe YOURSELF by sending a note to > > [EMAIL PROTECTED] with: > > subscribe mtu > > or > > subscribe mtu > > in the body. Please forward this message to anybody else who may be > > interested. > > > > Thanks, > > --MM-- 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
Keith, I'm doing my best to follow this thread, but one item in your note to Rich Draves has me confused: Keith Moore wrote: furthermore if you have multiple prefixes on a net, some of which are trusted and some which are not, then you have to configure each of those apps to tell them to use the trusted prefix. Can you say more about how this could occur in deployment scenarios? Prefixes come from router advertisements, stateful delegations (e.g., DHCPv6), or manual config - right? Are you saying that applications need to be configured in order to know which prefixes are legitimate and which are rogues? This sounds to me like either a site security issue or a requirement for an application-level prefix authentication mechanism - either way, it seems unrelated to the subject matter of this thread. Fred [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]
Re: FWD: I-D ACTION:draft-narten-ipv6-iana-considerations-00.txt
This question came up during one of the ISATAP draft revisions. We were intending to adopt Marc's proposed reserved address space for documentation, but couldn't find a proper reference. I favor the /16 example - it should be large enough to cover unanticipated future use cases. Fred [EMAIL PROTECTED] Marc Blanchet wrote: > > -- mercredi, octobre 23, 2002 10:43:58 -0400 Thomas Narten > <[EMAIL PROTECTED]> wrote/a icrit: > > >>I'd like to formally request the following from the WG on this >>document: >> >> - I'd like to see it become a WG document (to become a BCP RFC) >> >> - I'd like for folks here to review it and post any issues they have >> with it >> >> - I'd like to call special attention to the following text that it >> includes: >> >> >>> In addition, experience with IPv4 has shown that it is useful to >>> reserve an address block for documentation purposes that will never >>> be assigned for actual use in a network [DOC]. Such addresses can >>> safely be used in documentation, without the worry that someone will >>> accidentally (and incorrectly) configure them on a real network and >>> cause traffic intended for the legitimate owner of those addresses to >>> be impacted. >>> >>> This document reserves the IPv6 address block ::/32 for >>> documentation purposes. >> >>There has been some private discussion about the need for addresses >>for documentation, but it's probably worth discussing how much address >>space is needed for this purpose, and what the prefix should be (e.g., >>allocate out of 001/3?). the /32 length is a strawman. >> > > > - great to see that the proposal I made on address space for documentation > is surviving! > - I would propose that at least the space reserved is in well known > boundaries: /16, /24, /32. > - 3fff::/16 is for me the best: it is large, but simple and would cover > most cases needed. > - if not agreeable (too large), then /24. which would have room for > aggregates in bgp routing. > > Marc. > > > 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] > 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: (ngtrans) remote netaccess-threats via automatic tunneling
Pekka, Pekka Savola wrote: > > Getting kinda off-topic for this scope.. > > On Thu, 20 Dec 2001, Fred L. Templin wrote: > > In any case, however, the tunnel pseudo-interfaces are uniquely identified > > by the IPv4 address assigned to each. As long as different IPv4 addresses > > are assigned to the different tunnel pseudo-interfaces (a configuration > > requirement for FreeBSD and Linux, at least), there will never be a case > > of ambiguity such as the one you describe below. Note that if a single > > physical link were used, this would mean assigning two or more IPv4 > > addresses to the same link. But, all OS's I work with support this. > > How will the kernel police that local IPv4 address is different for each? Since this is getting off topic (as you say), I will refer you simply to the Linux 'sit.c' device driver found in: /usr/src/linux/net/ipv6/sit.c Preferrably, look at the version in the latest USAGI CVS tree at: http://www.linux-ipv6.org The answer to your question is that the kernel *does* enforce the local IPv4 address as different for each tunnel pseudo-interface as can easily be seen from reading the code. Fred [EMAIL PROTECTED] > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords 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: (ngtrans) remote netaccess-threats via automatic tunneling
"Fred L. Templin" wrote: > > There has clearly been some confusion caused by sloppy instructions > in my previous message; sorry about that. To close this out: > > 1) multiple tunnel pseudo=interfaces are supported under Linux > 2) the correct syntax for configuring an ISATAP auto-tunnel is: > ># ip tunnel add isatap0 mode isatap local V4ADDR > > where 'V4ADDR' is an IPv4 address assigned to a physical link. Please > see: Please see: http://v6web.litech.org/isatap/ for more details. Fred [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]
Re: (ngtrans) remote netaccess-threats via automatic tunneling
There has clearly been some confusion caused by sloppy instructions in my previous message; sorry about that. To close this out: 1) multiple tunnel pseudo=interfaces are supported under Linux 2) the correct syntax for configuring an ISATAP auto-tunnel is: # ip tunnel add isatap0 mode isatap local V4ADDR where 'V4ADDR' is an IPv4 address assigned to a physical link. Please see: Pekka Savola wrote: > > This is getting too implementation-specific, so I guess we had better kill > this thread, at least from here... > > > allows you to add as many auto-tunnel pseudo interfaces as you'd like. > > For example, try: > > > > # ip add tun1 mode sit remote R1 local L1 > > # ip add tun2 mode sit remote R2 local L2 > > ... > > # ip add tunn mode sit remote Rn local Ln > > Autotunnel/6to4 interfaces by definition don't have specific destinations; > this is useful for configured tunnels, though. (This is how configured > tunnels are created e.g. with probably most distributions). > > > and you should see n-many 'tun' pseudo-interfaces pop up when you > > issue the command: 'ifconfig -a'. (Above, Ri and Li represent the > > remote and local IPv4 addresses assigned to pseudo-interfaces 'tuni' > > for 1 <= i <= n). The 'sit0' is simply there as a "base" upon which > > multiple pseudo-interfaces may be layered. > > Multiple pseudo-interfaces should be possible, yes. But being built this > way, the kernel performing security checks cannot know which interface is > which. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords 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: (ngtrans) remote netaccess-threats via automatic tunneling
Vladislav,
If you use the 'iproute2' package under recent releases of the Linux
kernel (e.g. recent releases of 2.4.*), you will see that the command:
# ip tunnel add
allows you to add as many auto-tunnel pseudo interfaces as you'd like.
For example, try:
# ip add tun1 mode sit remote R1 local L1
# ip add tun2 mode sit remote R2 local L2
...
# ip add tunn mode sit remote Rn local Ln
and you should see n-many 'tun' pseudo-interfaces pop up when you
issue the command: 'ifconfig -a'. (Above, Ri and Li represent the
remote and local IPv4 addresses assigned to pseudo-interfaces 'tuni'
for 1 <= i <= n). The 'sit0' is simply there as a "base" upon which
multiple pseudo-interfaces may be layered.
If you get the 'iproute2' package from:
http://v6web.litech.org/isatap/
you will see the following when you issue the command: 'ip tunnel help':
> Usage: ip tunnel { add | change | del | show } [ NAME ]
> [ mode { ipip | gre | sit | isatap } ]
> [ remote ADDR ] [ local ADDR ] [ v4any ADDR ]
So, to create an ISATAP tunnel, simply use the "mode isatap" directive.
Fred
[EMAIL PROTECTED]
Vladislav Yasevich wrote:
>
> Fred
>
> I believe Pekka is comming from the linux implementation point of view
> which has only one pseudo-interface (sit0) to act as tunnel endpoint
> (at least that's what I see on my linux box). This is really the problem
> that leads to not being able to distinguish between tunneling mechanisms.
>
> -vlad
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: (ngtrans) remote netaccess-threats via automatic tunneling
Pekka, Let me respond to the below from the perspective of ISATAP and 6to4 tunnel mechanisms at work in the same machine. For example, let us suppose that a 6to4 router is also acting as an ISATAP router. In this case, there will be (at least) *two* distinct tunnel pseudo-interfaces; one for 6to4 and one for ISATAP. These pseudo-interfaces *may* bind to the same physical link, but they need not do so and (in practice) often will not. In any case, however, the tunnel pseudo-interfaces are uniquely identified by the IPv4 address assigned to each. As long as different IPv4 addresses are assigned to the different tunnel pseudo-interfaces (a configuration requirement for FreeBSD and Linux, at least), there will never be a case of ambiguity such as the one you describe below. Note that if a single physical link were used, this would mean assigning two or more IPv4 addresses to the same link. But, all OS's I work with support this. Am I belaboring an already obvious point? Fred [EMAIL PROTECTED] Pekka Savola wrote: > > First, let me point out a property of overloading protocol 41, from my > draft: > > --8<-- >There is a problem with multiple transition mechanisms if security is >implemented. This may vary a bit from implementation to >implementation. > >Consider three mechanisms using automatic tunneling: 6to4, ISATAP >[ISATAP] and Automatic Tunneling using Compatible Addresses [MECH]. > >All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with, >more or less, a pseudo-interface. > >When a router, which has any two of these enabled, receives an IPv4 >encapsulated IPv6 packet: > > src_v4 = 10.0.0.1 > dst_v4 = 20.20.20.20 > src = 3ffe:::1 > dst = 2002:1010:1010::2 > >what can it do? How should it decide which transitionary mechanism >this belongs to; there is no "transitionary mechanism number" in IPv6 >or IPv4 header to signify this. > >Without any kind of security checks (in any of implemented methods) >these often just "work" as the mechanisms aren't differentiated but >handled in "one big lump". > >Configured tunneling [MECH] does not suffer from this as it is point- >to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses >it can be deduced which logical tunnel interface is in the question. > >Solutions for this include not using more than one automatic >tunneling mechanisms in the same system or binding different >mechanisms to different IPv4 addresses. > --8<-- 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]
