[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt
Hi Pekka,
I see your point.
As more routers I try, more I find when isn't needed to configure anything: Is forwarded the same way as ICMP or other protocols.
But of course, this depends on each manufacturer, and even it can change. I also find some where ICMP is disabled by default ;-)
I think this is clearly a generic configuration issue in any "network box". Even it may depend in who install the router. For example, some ISPs change the manufacturer's default configuration.
We will post an updated version most probably after this meeting, and will including a clarification on this.
Regards,
Jordi
----- Original Message -----
From: "Pekka Savola" <pekkas@netcore.fi>
To: "Marc Blanchet" <Marc.Blanchet@hexago.com>
Cc: <v6ops@ops.ietf.org>; <jonne.soininen@nokia.com>; <mikael.lind@teliasonera.com>
Sent: Monday, March 01, 2004 6:30 AM
Subject: Re: WG Last Call: draft-ietf-v6ops-isp-scenarios-analysis-01.txt
> Thanks for your feedback!
>
> A few comments on your comments below.
>
> Jordi, there is one comment on proto-41 forwardaring below which is
> not IMHO clear -- could you check ?
>
> On Fri, 27 Feb 2004, Marc Blanchet wrote:
> > 3.2.1 Stage 1 Scenarios: Launch
> > ...
> >
> > The immediate first step consists of getting a prefix allocation
> > (typically a /32) from the appropriate RIR according to allocation
> > procedures.
> >
> > <MB>while clearly a good advice, not sure really useful to discuss here
> > given the objective of the document.</MB>
>
> There have been a couple of comments to even expand this, so I think
> this is probably a good pointer to start with.. not something that
> can or should be fully discussed, through.
>
> > The selection of one candidate depends largely on the presence or
> > absence of NATs between the two tunnel end-points and whether the
> > user's IPv4 tunnel end-point address is static or dynamic. In most
> > cases, 6to4 and ISATAP are incompatible with NATs, and UDP
> > encapsulation for configured tunnels has not been specified.
> >
> > <MB>configured tunnels with tunnel brokers [TSP] is specified for
> > NAT traversal.
> > </MB>
>
> True, but the issue remains: [MECH] or MECH-v2 doesn't do UDP.
>
> > However, NAT traversal can be avoided if the NAT supports
> > forwarding protocol-41 [PROTO41].
> >
> > <MB>s/protocol-41/protocol-41 and configured to do so./</MB>
>
> This is a point which I've tried to raise is that I think most
> protocol-41 forwarding implementations do automatically forward
> protocol-41 without any configuration -- just as they forward ICMP.
>
> If setting up proto-41 forwarding requires manual set-up (as discussed
> in a few places in the proto-41 forwarding draft), then it certainly
> would not be an option.
>
> Perhaps Jordi can clarify (and post an updated draft! :-)
>
> > The connectivity mechanisms can be categorized as "managed" or
> > "opportunistic." The former consist of native service or a
> > configured tunnel (with or without a tunnel broker); the latter
> > include 6to4 and, e.g., Teredo; they provide "short-cuts" between
> > nodes using the same mechanisms and are available without contracts
> > with the ISP.
> >
> > <MB>Teredo needs a Teredo server located outside of the NAT, which means
> > in the architecture presented in section 2, as customer connection network.
> > </MB>
>
> Teredo server doesn't have to be near the customer, it can be anywhere
> at all -- I wouldn't expect any ISPs to deploy it, in the short term
> at least. Suggested text?
>
> > Most interesting are the managed services. When dual-stack is not an
> > option, a form of tunneling must be used. When configured tunneling
> > is not an option (e.g., due to dynamic IPv4 addressing), some form of
> > automation has to be used. The options are basically either to deploy
> > an L2TP architecture (whereby the customers would run L2TP clients
> > and PPP over it to initiate IPv6 sessions) or to deploy a tunnel
> > configuration service. The prime candidates for tunnel configuration
> > are STEP [STEP] and TSP [TSP], which are not analyzed further in this
> > document.
> >
> > <MB>would also add that these services are able to do NAT traversal.
> > Suggesting:
> > s/are STEP and TSP , providing tunnels with or without the presence of NAT./
> > </MB>
>
> Seems to make sense to say that explicitly.
>
> > Note that when customers use dynamic IPv4 addresses, the
> > tunneling techniques may be more difficult to deploy at the ISP's
> > end, especially if a protocol including authentication (like PPP for
> > IPv6) is not used. This may need to be considered in more detail
> > with tunneling mechanisms.
> >
> > <MB>disagree for TSP. TSP re-establish the tunnel automatically in the
> > event of a change of IPv4 address
> > Suggesting replacing text:
> >
> > Note that when customers use dynamic IPv4 addresses, manually configured
> > tunneling techniques may be more difficult to deploy at the ISP's
> > end, especially if a protocol including authentication (like PPP for
> > IPv6) is not used. However, [TSP] does support automatic re-establishment
> > of the tunnel when the IPv4 address change.
> > </MB>
>
> I have to disagree with this -- STEP or TSP are not analyzed further
> in the document, at this point. Of course, they might be in the
> future, and if so, the feature(s) of TSP would certainly be mentioned.
>
> > 5.2 Access Control Requirements
> >
> >
> > When a provider does not wish to give its IPv4 customers
> > automatic access to IPv6 services, specific IPv6 access control must
> > be performed in parallel with the IPv4 access control. This does not
> > imply that different user authentication must be performed for IPv6,
> > but merely that the authentication process may lead to different
> > results for IPv4 and IPv6 access.
> >
> > <MB>to add:
> > The [TSP] tunnel broker provides the AAA capabilities to manage this
> > access control if desired.
> > </MB>
>
> Similarly, at the moment, I think TSP/STEP/ISATAP/etc. -specific
> issues are out of scope. This might change, based on this IETF
> though..
>
> > Note that when the customer connection network is shared between the
> > users or the ISPs, and not just a point-to-point link, authenticating
> > the configuration of the parameters (esp. prefix delegation) requires
> > further study.
> > <MB>TSP does it. to add:
> > TSP tunnel broker does prefix delegation in this context
> > </MB>
>
> Same as above.
>
> > This can be done, for example, by mapping a DHCP response to a
> > physical connection and storing this in a database. It can also be
> > done by assigning a static address or prefix to the customer.
> >
> > <MB>to add: TSP Tunnel broker provides this binding between user and
> > address and prefix delegated.</MB>
>
> Likewise.
>
> > 8.1 Example 1
> >
> > Customers (with some exceptions) are not connected using a tunnel
> > broker, because offering native service faster is considered more
> > important -- and then there will not be unnecessary parallel
> > infrastructures to tear down later on. However, a 6to4 relay is
> > provided in the meantime for optimized 6to4 connectivity.
> >
> > <MB>don't understand that argument. if "offering native service faster
> > is considered more important, then why care about 6to4 at all?
> > 6to4 relay should be considered similar to tunnel broker in terms
> > of ways to provide ipv6 through the not-yet-upgraded-ipv4 network.
> > </MB>
>
> This has come through from a couple of operators. They don't want to
> build tunnels etc. architecture because the difficult part about IPv6
> is considered to be the process/administrative issues, and it takes
> time to move from "hacks" to "real solutions" when the time comes --
> so they're going to "real solutions" as the first step. Of course,
> this could also be just an excuse :-).
>
> 6to4 relay can be used for two purposes:
> 1) to optimize the return routing between the native IPv6 users in
> your network and 6to4 users [this example], and
> 2) to optimize the use of 6to4 when your customers support it (this
> requires no support from the ISP, but offers the users better IPv6).
> This was not the main intent of the statement above, but comes in as a
> bonus.
>
> Suggestions for clarification?
>
> > <MB> adding tsp as reference
> >
> > [TSP] M. Blanchet, "IPv6 Tunnel broker with Tunnel Setup
> > Protocol(TSP)",
> > work in progress, draft-blanchet-v6ops-tunnelbroker-tsp-00, feb 2004
> > </MB>
>
> Right .. apparently these weren't added even though there is a
> reference in the text. Add STEP as well.
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.