[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Few comments:
a) I have seen much more confusion with 6to4 that with anything else. Most people think of it
as NAT IPv6 -> IPv4.
b) Many other encapsulation exists, not just v6/v4 & friends. The jargon "over" is used very widely,
like ATM over Sonnet, and, for instance, many of the documents in the Int area can be described
as "IP over foo". So creating a new jargon for just IPvx over IPvy may introduce even more
confusion.
c) More, asking all the standard bodies that used "foo over bar" terminology to
change to "foo in bar" just because there is a little use IETF protocol named "6over4"
does not sound very realistic.
d) 6over4 as a transition mechanism isn't used much, it might be simpler to just suggest to
either deprecate it or rename it, then restoring the original "foo over bar" terminology
as semantically equivalent to "foo in far".
- Alain.
________________________________
From: owner-v6ops@ops.ietf.org on behalf of JORDI PALET MARTINEZ
Sent: Sun 10/16/2005 5:54 PM
To: v6ops@ops.ietf.org
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Clue accepted ;-)
A new document has been submitted (attached for those that want to start
commenting already).
Regards,
Jordi
> De: Fred Baker <fred@cisco.com>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Mon, 15 Aug 2005 14:47:02 -0700
> Para: <jordi.palet@consulintel.es>
> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> Asunto: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
>
> On Aug 15, 2005, at 2:25 PM, JORDI PALET MARTINEZ wrote:
>> Overall, agree with your conclusions about 3.3, but I think there
>> is one more scenario, which is the one that we are facing, and
>> seems to me the right way to go, actually the natural one, being
>> deployed with some of our customers.
>>
>> ,---. ,---.
>> / \ / \
>> / \ / \
>> ; IPv4+6 : ; IPv4+6 :
>> | Network | | Network |
>> : +----+---. ,---. ,---. ,---+----+ ;
>> \ |GW-A| \ / \ / \ / |GW-D| /
>> \ +----+ +----+ \ / +----+ +----+ /
>> `---' ; IPv6 |GW-B| IPv4 : ; IPv4 |GW-C| IPv6 : `---'
>> | Network+----+ + | | + +----+Network |
>> ,---. :Transition : IPv6 : : IPv6 ,---.
>> / +----+A / \ B / \ C / \ D+----+ \
>> / |GW-A| / \ / \ / \ |GW-D| \
>> ; IPv4+6+----+--' `---' `---' `--+----+IPv4+6 :
>> | Network | | Network |
>> : ; : ;
>> \ / \ /
>> \ / \ /
>> `---' `---'
>>
>> Network A and D are IPv6-only, with GW-A and GW-B taking care of
>> the v4-in-v6 tunneling, automatically.
>
> There are certainly cases in which a consistent transition strategy
> is being followed and is working. I think I said something in the
> document about granting that the use of a single consistent strategy
> that works will probably work :^).
>
> What I am concerned about is the proliferation of inconsistent
> strategies, and the set of cases I can come up with in which they do
> not work. That is the issue I am trying to raise.
>
>> One more comment. I've discovered a lot of confusion in several
>> documents regarding 6over4 and 6in4, which is being followed by
>> confusing documents from vendors. I think is very important to make
>> a general recommendation, may be not just to this WG, but in
>> general to all the IETF documents which mention tunneling, to
>> clearly make a distinction between both mechanisms, probably
>> avoiding using "over" when actually is referring 6in4
>> encapsulation. Not sure if this should be raised at IESG level or
>> whatever. What do you think ?
>
> What you expect clue? :^)
>
> Yes, it would be good if people would say clueful things in a clueful
> way. There is probably room for an internet draft on the subject.
>