[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
I am fine with this spec content and objective. If we have folks use
incompatible transition mechanisms that can be a pain.
I don't believe IPv6 Dominant networks will cause a problem if there is
not IPv4 traffic edge, where there is an IPv4/IPv6 traffic edge like the
DSTM Border or a GRE router that must be dual IP capable, which is
required for a DSTM border router, so it can be used for dual IP packet
types.
Suggest adding reference to IPv6 Enterprise Scenarios RFC 4057.
thanks
/jim
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker
> Sent: Monday, August 15, 2005 5:47 PM
> To: jordi.palet@consulintel.es
> Cc: v6ops@ops.ietf.org
> Subject: 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.
>
>