Subject: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05

From: Acee Lindem <[email-masked]>
Date: Sat, 5 Jan 2013 11:42:53 +0000

We have WG last called the subject draft in the OSPF WG. It describes usage of a separate OSPFv3 instance in support of RFC 6052 address translation. 
Please comment by Saturday, January 19th, 2013. Here is a URL to the subject document: 

http://www.ietf.org/id/draft-ietf-ospf-ipv4-embedded-ipv6-routing-05.txt

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Thu, 24 Jan 2013 20:17:48 +0000

All, 
Since we haven't received any comments on the subject draft we must assume that the BEHAVE WG is happy with its content. We will proceed to request publication.
Thanks,
Acee Lindem
Co-chair of the OSPF WG
On Jan 5, 2013, at 6:42 AM, Acee Lindem wrote:

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 24 Jan 2013 15:35:47 -0500

On Thu, Jan 24, 2013 at 08:17:48PM +0000, Acee Lindem wrote:
> Since we haven't received any comments on the subject draft we must
> assume that the BEHAVE WG is happy with its content. 

I object to the conclusion.  Non-review is not evidence of support.
If you can't get five people who say they read the draft and support
it, then there's no reason to suppose people think it's a good idea.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Acee Lindem <[email-masked]>
Date: Thu, 24 Jan 2013 20:45:42 +0000

> it, then there's no reason to suppose people think it's a good idea.

Sufficient time has been provided for input and we've already gone through several review cycles in the OSPF WG. We provided the BEHAVE the opportunity to comment since the draft is based on RFC 6052 (which was in my original E-mail but clipped from your reply). You are welcome to review it as part of the IETF last call. 

Thanks,
Acee

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 24 Jan 2013 16:22:12 -0500

> Sufficient time has been provided for input and we've already gone through several review cycles in the OSPF WG. We provided the BEHAVE the opportunity to comment since the draft is based on RFC 60…

Well, I can provide this review: I don't understand the value of the
proposal.

As nearly as I can tell, it is a redundant mechanism that does not
push existing v4-only networks towards IPv6 deployment.  To the extent
that's true, I don't think it should be pursued.  There appear to be
two use cases listed in the document, but I can't say how compelling I
find them.

The IETF seems to have contracted Perl disease, in that we want to
have More Than One Way To Do It for every possible transition
strategy.  I think this is nuts.

I don't especially care if the draft goes ahead, and from the
peremptory tone of this thread I presume it will.  But I think all
this redundancy (of methods to aid in the preservation of a network
technology we might properly wish would go away) is a mistake.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Acee Lindem <[email-masked]>
Date: Thu, 24 Jan 2013 21:45:31 +0000

On Jan 24, 2013, at 4:22 PM, Andrew Sullivan wrote:

> that's true, I don't think it should be pursued.

Using this reasoning, the same could be said for RFC 6052 and RFC 6145. Given that the RFC 6052/RFC 6145 mechanisms exist, this is merely an informational draft describing how one could use OSPFv3 address families to route between the IPv4 and IPv6 domains. 

Acee

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Jan 2013 16:12:51 +0000

> Using this reasoning, the same could be said for RFC 6052 and RFC 6145. Given that the RFC 6052/RFC 6145 mechanisms exist, this is merely an informational draft describing how one could use OSPFv3…

I think the problem is that the scenario analysis isn't adequate.
There is no discussion of the relationship with the various
scenarios described in RFC 6144 - this seems to be an extension
from there, but it should be explained.

It would be nice to hear how it compares to draft-ietf-v6ops-464xlat.
The latter is not aimed at IPv4 peer-to-peer communication, but
only at client-server with no inbound connections. Is this different?

Given that "the IPv4 and IPv6 header translation performed in both
directions by the AFXLBR is stateless", does that imply that only
global IPv4 addresses are supported and the solution is transparent
to ports and upper layers?

    Brian

---

From: Acee Lindem <[email-masked]>
Date: Sat, 26 Jan 2013 16:54:55 +0000

> to ports and upper layers?

I'll defer to the authors. 
Thanks,
Acee

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 26 Jan 2013 10:12:24 -0800

Sent from ipv6-only Android
On Jan 26, 2013 8:12 AM, "Brian E Carpenter" <[email-masked]>
wrote:
> >>> Sufficient time has been provided for input and we've already gone
through several review cycles in the OSPF WG. We provided the BEHAVE the
opportunity to comment since the draft is based on RFC 6052 (which was in
my original E-mail but clipped from your reply). You are welcome to review
it as part of the IETF last call.
> > Using this reasoning, the same could be said for RFC 6052 and RFC 6145.
Given that the RFC 6052/RFC 6145 mechanisms exist, this is merely an
informational draft describing how one could use OSPFv3 address families to
route between the IPv4 and IPv6 domains.
> to ports and upper layers?

464xlat implies stateful 6146 translation while this only uses 6145.

That said, it seems more similar to map-t

CB _______________________________________________

---

From: Dean cheng <[email-masked]>
Date: Mon, 28 Jan 2013 23:14:10 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brian E Carpenter
> Sent: Saturday, January 26, 2013 8:13 AM
> To: Acee Lindem
> Cc: <[email-masked]>; Andrew Sullivan
> Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-
> ietf-ospf-ipv4-embedded-ipv6-routing-05
> 
> through several review cycles in the OSPF WG. We provided the BEHAVE
> the opportunity to comment since the draft is based on RFC 6052 (which
> was in my original E-mail but clipped from your reply). You are welcome
> to review it as part of the IETF last call.
> >>>
> > Using this reasoning, the same could be said for RFC 6052 and RFC
> 6145. Given that the RFC 6052/RFC 6145 mechanisms exist, this is merely
> an informational draft describing how one could use OSPFv3 address
> families to route between the IPv4 and IPv6 domains.
> 

We can add some text to clarify this if that helps; in fact the 
scenario we described here is exactly the same as that in RFC5565 
(published 2 years earlier than RFC6144), as so stated in Section 1.2.

> only at client-server with no inbound connections. Is this different?

There are differences as said here also in Cameron Byrne's email. We 
can add some text to explain; we did not intend to run a general 
comparison with others here though.

> to ports and upper layers?

This draft describes an application based on RFC6052 and RFC6045 along 
with OSPFv3 MI/MT flavor, and so restrictions as defined in those are applied, 
including that the use of well-known IPv6 address prefix not to be used 
to represent non-global IPv4 addresses, and the translation does not 
touch those beyond IP header.

Dean

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Jan 2013 08:02:48 +0000

Dean,

Thanks. IMHO it's very important to get these points about the
deployment scenario very clear in the document. Otherwise the
spec could be widely misinterpreted as providing something more
than it does.

Regards
   Brian