Subject: [MBONED] mboned: AMT ipv6 question

From: Toerless Eckert <[email-masked]>
Date: Mon, 11 Feb 2008 13:27:27 -0800

If i have for example home gateway (router in the home) with just
  IPv4 (unicast) connectivity to the backbone, but i want to use IPv6
  multicast...:

  - Do i remember correctly, that all of 6to4 6over4 6***4 will not support that ?

  - Would i be able to use AMT for this ?

    I thought i should, but i can't find any explicit sentence in the draft.  aka:

    - If it's meant to be supported by AMT, could this be written
      somewhere explicitly for lazy readers like myself (somewhere in the
      section "summary of value propositions" ;-))

    - If it's not meant to be supported, then why not ?

Thanks
    Toerless
_______________________________________________
MBONED mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mboned

---

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Feb 2008 08:09:13 +0200 (EET)

>    - If it's not meant to be supported, then why not ?

First you'll need to obtain unicast IPv6 connectivity.  You can get 
this using 6to4, manually configured ipv6 tunnel, or whatever 
mechanism.

Then you just use AMT on top of that.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- GeorgFrom [email-masked]  Mon Feb 11 22:08:31 2008
Date: Tue, 12 Feb 2008 08:09:13 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: Toerless Eckert <[email-masked]>
Cc: [email-masked]
Subject: Re: [MBONED] mboned: AMT ipv6 question
Sender: [email-masked]

>    - If it's not meant to be supported, then why not ?

First you'll need to obtain unicast IPv6 connectivity.  You can get 
this using 6to4, manually configured ipv6 tunnel, or whatever 
mechanism.

Then you just use AMT on top of that.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
MBONED mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mboned

e R.R. Martin: A Clash of Kings
_______________________________________________
MBONED mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mboned

---

From: "Greg Shepherd" <[email-masked]>
Date: Tue, 12 Feb 2008 07:24:01 -0800

> Then you just use AMT on top of that.

Pekka,

I don't think that addresses Toerless' question. The premise was that
the end-node had ONLY IPv4 connectivity but the content was sourced
over IPv6.

I believe this is possible but it posses some interesting permutations
of both the relay and gateway, but not necessarily any changes in the
AMT protocol. But perhaps the draft should explicitly define behavior
for this scenario where the pseudo interface address family can be
different from the address-family of the join messages and data.

Greg

---

From: "Greg Shepherd" <[email-masked]>
Date: Tue, 12 Feb 2008 07:24:01 -0800

Pekka,

Greg

---

From: "Greg Shepherd" <[email-masked]>
Date: Tue, 12 Feb 2008 07:28:38 -0800

> different from the address-family of the join messages and data.

Oops - should be:

The address-family of the physical interfaces and anycast address can
be different from the address-family of the pseudo interfaces, join
messages, and data.

Greg

---

From: "Greg Shepherd" <[email-masked]>
Date: Tue, 12 Feb 2008 07:28:38 -0800

Oops - should be:

Greg

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Feb 2008 10:24:51 -0800

> be different from the address-family of the pseudo interfaces, join

I believe protocol changes are required. One has to decide that if an  
AMT update in MLD format is sent over an IPv4 transport, that the  
gateway is requesting IPv6 content based on the (S,G) it is joining to  
be delivered over IPv4.

That could be the simplest way to negotiate the cross-over. But I  
think we might want to consider if a particular Relay would want to  
deny the above request and inform the Gateway to join "the other AF".

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Feb 2008 10:24:51 -0800

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 12 Feb 2008 10:46:07 -0800

> deny the above request and inform the Gateway to join "the other AF".

Let's see:

a) Do we agree that it would be beneficial to support
   IPv6 multicast across an IPv4 AMT tunnel ?

   Aka: If we can not do this, then we would be stuck with what
   Pekka suggested, and that would mean double tunneling ->
   IPv6 multicast 
   (encap) AMT IPv6 GRE/UDP unicast
   (encap) 6to4 IPv4 unicast

   And avoiding double encap should be a sufficient reason, right ?

b) Negotiation sounds fine, although i guess a gateway should
   only request MLD joins via IPv4 if it really can't do native
   IPv6, so if it get's the reply "join the other AF" from the relay,
   then it just means it won't work.

   So that brings us to:

c) If you folks can update the draft to describe this situation
   (v6 multicast over v4 AMT tunnel), then the question is
   whether it is a MUST or SHOULD, and my recommendation would be:

   An AMT relay/gateway SHOULD support v6 over AMT v4.

   An AMT relay/gateway that also supports 6to4 MUST support it.

   Aka: This would be suggesting that because there is no other
   IPv6 multicast over IPv4 defined by the IETF (AFAIR), we could try
   to establish AMT for this (even though operationally it's not
   quite the same). And given that 6to4 is seemingly becoming the
   mandatory requirement due to vista certification (i think this
   is the term), it would make perfect sense to hop onto that
   bandwagon ;-))

   (obviously, i am smoking too much here, and somebody will come
    along and deny this request, but this still would be IMHO the best
    chance for getting at least IPv6 multicast out there ;-))

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 12 Feb 2008 10:46:07 -0800

Let's see:

   So that brings us to:

Cheers
    Toerless

---

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Feb 2008 20:54:33 +0200 (EET)

>   And avoiding double encap should be a sufficient reason, right ?

Similar question has been visited in various different WGs when they 
wanted to specify their own IPv6-IPv4 transition mechanism; in some 
cases the result was a new transition mechanism (usually after very 
lengthy debates and a lot of analysis and justification of the case), 
in some others they ended up using whatever was already in the 
toolbox.

In my opinion, avoiding double encapsulation is not a sufficient 
reason.  Adding signalling capability and all the issues that come 
with transition mechanisms are non-trivial.

The spec is already way too much delayed.  The IPv6 transition toolbox 
already offers mechanisms to solve this case.  We don't _need_ to 
solve this, at least right now, in the initial spec.

Just ship the spec.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 12 Feb 2008 20:54:33 +0200 (EET)

Just ship the spec.

---

From: "Greg Shepherd" <[email-masked]>
Date: Tue, 12 Feb 2008 11:03:21 -0800

> gateway is requesting IPv6 content based on the (S,G) it is joining to

I think we need to clarify terms - are at least I need some
clarification. :p What do you consider the transport? Couldn't the
tunnel endpoints be IPv4 but the psuedo ifcs be IPv6?

Greg

---

From: "Greg Shepherd" <[email-masked]>
Date: Tue, 12 Feb 2008 11:03:21 -0800

Greg

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 12 Feb 2008 11:15:10 -0800

I do not agree with your conclusion. There are many different
v4 to v6 transition mechanisms invented and deployed for unicast.
Obviously the need for one more will cause lengthy debates.

There is no IETF agreed upon IPv6 to IPv4 migration solution
for IPv6 multicast at all. This puts it into a different ballpark.

If supporting this with AMT is as simple as Dino describes it
then i think it is well worth capturing this explicitly in the
text now to avoid another lengthy round of RFC update. Especially
because i think that with vista certification and 6to4 usage,
there is going to be quite a bit of v6 over v4 unicast only
deployments going to happen, so this is probably a very good time
to deliver and promote a multicast solution.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 12 Feb 2008 11:15:10 -0800

Cheers
    Toerless

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 12 Feb 2008 22:31:33 -0800

> clarification. From [email-masked]  Tue Feb 12 22:30:22 2008
From: Dino Farinacci <[email-masked]>
To: Greg Shepherd <[email-masked]>
Date: Tue, 12 Feb 2008 22:31:33 -0800
Cc: [email-masked]
Subject: Re: [MBONED] mboned: AMT ipv6 question
Sender: [email-masked]

> tunnel endpoints be IPv4 but the psuedo ifcs be IPv6?

This is what I mean:

o Applications are IPv6 multicast applications. They build IPv6  
multicast headers.
o Applications join (S,G) via MLD.
o An AMT Update message is comprised of the following headers:

	MLD Report -> IPv6 multicast -> UDP -> IPv4 unicast

o Same for a Relay sending AMT Queries:

	MLD Query -> IPv6 multicast -> UDP -> IPv4 unicast

We could do this in the opposite order as well when you want to run  
IPv4 multicast over an IPv6 unicast infrastructure.

Dino

:p What do you consider the transport? Couldn't the
> tunnel endpoints be IPv4 but the psuedo ifcs be IPv6?

This is what I mean:

o Applications are IPv6 multicast applications. They build IPv6  
multicast headers.
o Applications join (S,G) via MLD.
o An AMT Update message is comprised of the following headers:

	MLD Report -> IPv6 multicast -> UDP -> IPv4 unicast

o Same for a Relay sending AMT Queries:

	MLD Query -> IPv6 multicast -> UDP -> IPv4 unicast

We could do this in the opposite order as well when you want to run  
IPv4 multicast over an IPv6 unicast infrastructure.

Dino

---

From: Stig Venaas <[email-masked]>
Date: Wed, 13 Feb 2008 09:52:42 +0100

Pekka Savola wrote:
> In my opinion, avoiFrom [email-masked]  Wed Feb 13 00:51:24 2008
Date: Wed, 13 Feb 2008 09:52:42 +0100
From: Stig Venaas <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: [email-masked], Greg Shepherd <[email-masked]>
Subject: Re: [MBONED] mboned: AMT ipv6 question
Sender: [email-masked]

> solve this, at least right now, in the initial spec.

I agree. If there is interest in solving that, do that as an
extension, a follow-up draft.

I think the best way to avoid double encap is to get people to
deploy multicast in their IPv6 networks. As many have found, it's easier
to deploy IPv6 multicast than IPv4 multicast (once you have IPv6).
When people deploy IPv6 unicast, they should also deploy multicast.
With SSM, and also embedded-RP, this is trivial. Many of the existing
IPv6 tunneling mechanisms can do "native" (inside the tunnel, i.e., no
double encap). I guess one could also try to make say Teredo support
multicast...

Stig

ding double encapsulation is not a sufficient 
> solve this, at least right now, in the initial spec.

I agree. If there is interest in solving that, do that as an
extension, a follow-up draft.

I think the best way to avoid double encap is to get people to
deploy multicast in their IPv6 networks. As many have found, it's easier
to deploy IPv6 multicast than IPv4 multicast (once you have IPv6).
When people deploy IPv6 unicast, they should also deploy multicast.
With SSM, and also embedded-RP, this is trivial. Many of the existing
IPv6 tunneling mechanisms can do "native" (inside the tunnel, i.e., no
double encap). I guess one could also try to make say Teredo support
multicast...

Stig

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 13 Feb 2008 10:29:26 -0800

Well I looked at the packFrom [email-masked]  Wed Feb 13 10:28:15 2008
From: Dino Farinacci <[email-masked]>
To: Stig Venaas <[email-masked]>
Date: Wed, 13 Feb 2008 10:29:26 -0800
Cc: [email-masked], Greg Shepherd <[email-masked]>
Subject: Re: [MBONED] mboned: AMT ipv6 question
Sender: [email-masked]

Well I looked at the packet formats and they can go in either IPv4 or  
IPv6 format. Since the Update is encapsulated in IGMP or MLD it is  
clear the size of the address. But for the Relay Advertisement  
message, we have:

/*
  * AMT Relay Advertisement
  *
  *  0                   1                   2                   3
  *  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  * |     Type=0x2  |     Reserved                                  |
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  * |            Discovery Nonce                                    |
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  * |            Relay Address                                      |
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  */
typedef struct {
     uchar type;
     uchar reserved[3];
     ulong discovery_nonce;
     uchar relay_address[0];    /* IPv4 or IPv6 depending on packet  
length */
} PACKED amt_advertise_pkt;

And the way I implemented it the Relay Address above is in IPv4 versus  
IPv6 based on the UDP length. Not sure what the spec said about this,  
but this is the only "protocol-family independent" message in AMT.

Dino

et formats and they can go in either IPv4 or  
IPv6 format. Since the Update is encapsulated in IGMP or MLD it is  
clear the size of the address. But for the Relay Advertisement  
message, we have:

/*
  * AMT Relay Advertisement
  *
  *  0                   1                   2                   3
  *  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  * |     Type=0x2  |     Reserved                                  |
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  * |            Discovery Nonce                                    |
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  * |            Relay Address                                      |
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  */
typedef struct {
     uchar type;
     uchar reserved[3];
     ulong discovery_nonce;
     uchar relay_address[0];    /* IPv4 or IPv6 depending on packet  
length */
} PACKED amt_advertise_pkt;

And the way I implemented it the Relay Address above is in IPv4 versus  
IPv6 based on the UDP length. Not sure what the spec said about this,  
but this is the only "protocol-family independent" message in AMT.

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 13 Feb 2008 18:49:09 -0800

> to deploy IPv6 multicast than IPv4 multicast (once you have IPv6).

As i said, the primarily incentive here would be support of
IPFrom [email-masked]  Wed Feb 13 18:50:08 2008
Date: Wed, 13 Feb 2008 18:49:09 -0800
From: Toerless Eckert <[email-masked]>
To: Stig Venaas <[email-masked]>
Cc: [email-masked], Greg Shepherd <[email-masked]>
Subject: Re: [MBONED] mboned: AMT ipv6 question
Sender: [email-masked]

> to deploy IPv6 multicast than IPv4 multicast (once you have IPv6).

As i said, the primarily incentive here would be support of
IPv4 only network connectivity. There's likely a lot of IPv4 over
IPv4 only going to happen purely because Windows Vista not only
supports this by default (6to4), but also because they mandate it
in any "vista compliant" prodcuts as far as i understand it.

Aka: as much as we all agree thatnative IPv6 is best (and native
IPv6 multicast even more so), it's quite likely that mass inertia will
actually have more 6to4 happening, and then multicast is stuck unless
we make sure the AMT spec would support this - IMHO! 

Cheers
    Toerless

v4 only network connectivity. There's likely a lot of IPv4 over
IPv4 only going to happen purely because Windows Vista not only
supports this by default (6to4), but also because they mandate it
in any "vista compliant" prodcuts as far as i understand it.

Aka: as much as we all agree thatnative IPv6 is best (and native
IPv6 multicast even more so), it's quite likely that mass inertia will
actually have more 6to4 happening, and then multicast is stuck unless
we make sure the AMT spec would support this - IMHO! 

Cheers
    Toerless

---

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Feb 2008 07:39:15 +0200 (EET)

> we make sure the AMT spec would support this - IMHO!

AMT spec already supports it.  Nothing is needed if you deploy AMT on 
a system that already has IPv6 connectivity through the use of 6to4. 
What you want is to create an optimization.

What is needed much more is that we finish the spec (itFrom [email-masked]  Wed Feb 13 21:38:15 2008
Date: Thu, 14 Feb 2008 07:39:15 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: Toerless Eckert <[email-masked]>
Cc: [email-masked], Greg Shepherd <[email-masked]>,
	Stig Venaas <[email-masked]>
Subject: Re: [MBONED] mboned: AMT ipv6 question
Sender: [email-masked]

> we make sure the AMT spec would support this - IMHO!

AMT spec already supports it.  Nothing is needed if you deploy AMT on 
a system that already has IPv6 connectivity through the use of 6to4. 
What you want is to create an optimization.

What is needed much more is that we finish the spec (it has already 
been *7* years from -00 WG draft!) so that more implementors would 
have a stable base from which to create their implementations, and 
that we would have a prefix from IANA which could be used for 
deployments.

 has already 
been *7* years from -00 WG draft!) so that more implementors would 
have a stable base from which to create their implementations, and 
that we would have a prefix from IANA which could be used for 
deployments.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 13 Feb 2008 22:47:54 -0800

> What you want is to create an optimization.

What you call an optimization is most likely the difference between being
able to build an AMT relay with hardware accelerated forwarding or not
for IPv6 multicast across IPv4 only networks. Like the UDP checksum
discussion etc. those optimizations are crucial. One could even argue
AMT by itsel is "just"an optimization (UDP instead of GRE to get easier
through NAT, to easier allow host stack implementations, anycast to
easer configure,...).

> that we would have a prefix from IANA which could be used for 

Yeah, well. We kept quiet for almost 2 years at the end of the PIM-SM
draft to get it through as fast as possible and it still took 2 years
to get through (rfc4601). And in this case of AMT we're not talking
about new functionality but just something that as far as i see it
is elready easily within the scope of the protocol and just needs some
better wording to be emphasized as a supported mode of operation. One
that could be quite crucial.

And we had a perfectly non-functional PIM-SM spec for something like
8 years, that didn't stop PIM-SM deployment either. Or no MSDP RFC.
And what, we had the IGMPv3 spec for years and still Apple doesn't
support it, yada yada yada. Don't tell me you can predict the
correlation between the success of a technology and the RFC status.

Let's just try to get the best job done we can, and not only worry
primarily about the output rate of RFCs. I agree expedience is important,
but so is covering the crucial deployment opportunities.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 13 Feb 2008 22:47:54 -0800

Cheers
    Toerless

---

From: "Greg Shepherd" <[email-masked]>
Date: Thu, 14 Feb 2008 10:37:57 -0800

Yes, I'm going to say this publicly - I completely agree with
Toerless. Our goal here should be to get it right.

Greg

On Wed, Feb 13, 2008 at 10:47 PM, Toerless Eckert <[email-masked]> wrote:
>  > AMT spec already supports it.  Nothing is nFrom [email-masked]  Thu Feb 14 10:36:39 2008
Date: Thu, 14 Feb 2008 10:37:57 -0800
From: "Greg Shepherd" <[email-masked]>
To: "Toerless Eckert" <[email-masked]>
Cc: [email-masked], Stig Venaas <[email-masked]>
Subject: Re: [MBONED] mboned: AMT ipv6 question
Sender: [email-masked]

Yes, I'm going to say this publicly - I completely agree with
Toerless. Our goal here should be to get it right.

Greg

eeded if you deploy AMT on

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 17 Feb 2008 11:13:25 -0500

> but so is covering the crucial deployment opportunities.

Speaking just as a WG member, I fully agree with Toerless here.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 17 Feb 2008 11:13:25 -0500

Regards
Marshall