Subject: [MBONED] AMT IGMP/MLD source addr - followup from Paris WG meeting

From: Kurt Windisch <[email-masked]>
Date: Mon, 9 Apr 2012 09:01:28 -0700

I just wanted to follow up on my comments during the WG meeting in Paris before the AMT spec is submitted for WGLC.

The update given for version 12 claims backwards compatibility. With that in mind, since there was general support in the room for the idea to specify a non-zero address to be used within encapsulated IGMP and MLD packets, can we try to specify this also in a backwards compatible way, where possible?

First a few questions since minutes are not available yet to double check:
Is the proposal to specify a well known address to be used just for IGMP/MLD Query messages or is it for Report/Leave messages also? (I think previous versions allowed for Report/Leave messages to be encapsulated without modification.)

Regarding backwards compatibility, it looks like the MLD spec requirement to ignore packets with a non-link local IP source address is simply not compatible with the old AMT spec which called for the relay to use the relay anycast address as the IP source. I don't see how this can be reconciled in any backwards compatible way so I am putting MLD aside.

However, for IGMP we don't have the same restrictions and it should be possible to specify AMT in a backwards compatible way, while still keeping the new AMT packet addressing consistent between IGMP and MLD (both using a well-known source addr as suggested in the WG meeting). 

Ideally, that would mean something like:
* When sending encapsulated IGMP packets, a relay or gateway implementation SHOULD use the assigned, well-known source address.
* When receiving encapsulated IGMP packets, a relay or gateway implementation SHOULD NOT reject packets based upon the source address of the encapsulated IGMP/MLD packet.

I think this would ensure two-way compatibility between relays and gateways conforming to the new or old specs with respect to IGMP.

Some points of reference:

* The AMT version 09 spec for the relay's use of the anycast address as IP source:
  http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-09#section-6.4.5
  "The IP source address of the query would match the anycast address 
  on the pseudo interface."

* The AMT version 09 spec does not dictate anything regarding IP source
  of encapsulated IGMP/MLD packets sent by the gateway.

* The AMT version 09 spec regarding use of IP source in received AMT pkts:
  http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-09#section-6.5
  "The relay is not required to use the IP source address of the IGMP
   Membership Report for any particular purpose."

* The MLDv2 RFC is explicitly restrictive about handling of packets 
  with respect to the source address: 
  http://tools.ietf.org/html/rfc3810#section-5.2.13
  "...routers MUST silently discard a message that is
   not sent with a valid link-local address, without taking any action
   on the contents of the packet."

Thanks
--Kurt

---

From: Greg Bumgardner <[email-masked]>
Date: Mon, 09 Apr 2012 10:10:58 -0700

Kurt,

Comments below...

-g.b.

> The update given for version 12 claims backwards compatibility. With that in mind, since there was general support in the room for the idea to specify a non-zero address to be used within encapsula…
I think we can do this with SHOULD language combined with an 
explicit/implicit requirement that the recipient of the message take 
responsibility for modifying the source address if required. Ideally, 
one would not want to modify the incoming message packets as this would 
necessitate a recomputation of the IPv4 or ICMPv6 checksums, but the 
cost for doing so would be trivial on the gateway end.

The draft might be modified to indicate that relays and gateways SHOULD 
use an IPv6 address from the IANA assigned range as the source address 
in IGMP messages and use an IPv6 link-local address (e.g. FE80::X) in 
MLD messages. This implies that relays and gateways may generate message 
packets that do not carry a valid link local address and that the 
recipient cannot assume that these packets do.

For IPv6, we might want to add a blurb regarding address collisions - 
auto conf cannot be used to ensure unique link local addresses for the 
gateways connected to a relay - some may return a synthesized link local 
address or an AMT designated address, such as FE80::2.
> Is the proposal to specify a well known address to be used just for IGMP/MLD Query messages or is it for Report/Leave messages also? (I think previous versions allowed for Report/Leave messages to…
I believe that MLD requires a link local address for both. The IGMP spec 
also indicates that the messages should carry a link-local address (same 
subnet), but also allows for the use of the unspecified address 
(0.0.0.0) in report messages (but not query messages if I recall correctly).
> Regarding backwards compatibility, it looks like the MLD spec requirement to ignore packets with a non-link local IP source address is simply not compatible with the old AMT spec which called for t…
Yes, MLD was the reason I brought this up in the mboned session.
> * When receiving encapsulated IGMP packets, a relay or gateway implementation SHOULD NOT reject packets based upon the source address of the encapsulated IGMP/MLD packet.
Agreed. And if the source address is NOT a link local address and the 
relay or gateway implementation requires one, that the recipient must 
modify the source address if required. However, I don't think this 
statement represents a requirement, but might appear in the draft to 
explain the use of SHOULD.
>    on the pseudo interface."
I suppose this would work if an address with the anycast prefix could 
also be assigned to the gateway interface specifically for use in AMT, 
e.g., a relay might use .1 while gateways use .2. This approach might be 
used to support multiple AMT virtual interfaces on a gateway where 
individual interfaces are differentiated by the anycast address used by 
that interface.
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>

---

From: Greg Bumgardner <[email-masked]>
Date: Mon, 09 Apr 2012 10:18:36 -0700

Correction below...

-g.b.

On 4/9/12 10:10 AM, Greg Bumgardner wrote:
>> I just wanted to follow up on my comments during the WG meeting in 
>> Paris before the AMT spec is submitted for WGLC.
>>
>> The update given for version 12 claims backwards compatibility. With 
>> that in mind, since there was general support in the room for the 
>> idea to specify a non-zero address to be used within encapsulated 
>> IGMP and MLD packets, can we try to specify this also in a backwards 
>> compatible way, where possible?
> one would not want to modify the incoming message packets as this 
> would necessitate a recomputation of the IPv4 or ICMPv6 checksums, but 
> the cost for doing so would be trivial on the gateway end.
>
> The draft might be modified to indicate that relays and gateways 
> SHOULD use an IPv6 address from the IANA 
Obviously meant IPv4 address. Possible values for a /30 allocation in 
the ISC block might be something like
154.17.1.1 for a Relay
154.17.1.2 for a Gateway
> assigned range as the source address in IGMP messages and use an IPv6 
> link-local address (e.g. FE80::X) in MLD messages. This implies that 
> relays and gateways may generate message packets that do not carry a 
> valid link local address and that the recipient cannot assume that 
> these packets do.
>
> gateways connected to a relay - some may return a synthesized link 
> local address or an AMT designated address, such as FE80::2.
>>
>> Is the proposal to specify a well known address to be used just for 
>> IGMP/MLD Query messages or is it for Report/Leave messages also? (I 
>> think previous versions allowed for Report/Leave messages to be 
>> encapsulated without modification.)
> I believe that MLD requires a link local address for both. The IGMP 
> spec also indicates that the messages should carry a link-local 
> address (same subnet), but also allows for the use of the unspecified 
> address (0.0.0.0) in report messages (but not query messages if I 
> recall correctly).
>>
>> Regarding backwards compatibility, it looks like the MLD spec 
>> requirement to ignore packets with a non-link local IP source address 
>> is simply not compatible with the old AMT spec which called for the 
>> relay to use the relay anycast address as the IP source. I don't see 
>> how this can be reconciled in any backwards compatible way so I am 
>> putting MLD aside.
>> However, for IGMP we don't have the same restrictions and it should 
>> be possible to specify AMT in a backwards compatible way, while still 
>> keeping the new AMT packet addressing consistent between IGMP and MLD 
>> (both using a well-known source addr as suggested in the WG meeting).
>>
>> * When sending encapsulated IGMP packets, a relay or gateway 
>> implementation SHOULD use the assigned, well-known source address.
>> * When receiving encapsulated IGMP packets, a relay or gateway 
>> implementation SHOULD NOT reject packets based upon the source 
>> address of the encapsulated IGMP/MLD packet.
>> I think this would ensure two-way compatibility between relays and 
>> gateways conforming to the new or old specs with respect to IGMP.
>>
> e.g., a relay might use .1 while gateways use .2. This approach might 
> be used to support multiple AMT virtual interfaces on a gateway where 
> individual interfaces are differentiated by the anycast address used 
> by that interface.
>>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Apr 2012 07:37:59 -0700

>   implementation SHOULD NOT reject packets based upon the source 
...

I don't think that these requirements are not sufficient to guarantee
interoperability between senders and receivers. I think we need to change
the second SHOULD to a MUST. I would also like to extend the second
requirement to IGMP and MLD.

The source-IP address in the IGMP/MLD packet is irrelevant. It does not
carry any information. The reasons to worry about it seem to include:

a) Compatibility with existing AMT implementations.
   
   I am not sure how important it is to worry about this. I would hope
   it is very important because there are lots of AMT relays/gateways
   out there, but i am not counting ;-)

   By mandating a "MUST accept any upon receipt" we do create full
   compatibility in one direction. By using designated addresses especially
   in the queries i think we also maximize compatibility on sending to
   old receivers.

b) Leveraging existing IGMP/MLD stacks

   There seems to be the thought that an AMT relay or gateway could
   leverage an existing IGMP/MLD stack abd that therefore the
   use of non-standards-compliant source-addresses especially in IPv4
   could cause incompatibilities. And the idea to overcome this issue
   would then be to have the AMT layer fix-up the source-IP address
   upon receipt to make it compatible with the pre-existing stack again,
   right (i am deducing this from the prior mails on this thread).

   Do we actually have any tracking of implementations that would run
   into this issue ? Eg: any specific implementation known That could
   not just accept the arbitrary address (both relay and gateway) ?

   I really can't see how we could make all possible existing implementtions
   happy. For example, what happens if a gateway wants to have two AMT
   tunnels and tries to use kernel-level tunnel interfaces to do AMT,
   and then effectively has two interfaces which likely can not both
   have the same ip addresses. That's the reason for the "SHOULD"on the
   send side. But of course, if the first tunnel uses 154.17.1.2 and
   the second some other address 192.168.125.2, and then this gateway
   would see IGMPv3 queries from 154.17.1.1, then that gateway stack
   might not be happy wit this either. So the whole intent of being
   able to use arbitrary existing IGMP stacks might not pan out afer all.

   Aka: The best IMHO we can do is to normatively ignore this problem,
   but write some thoughts like the above into some different section
   of the AMT doc to indicate what gateways/relays could do to deal
   with source-addersses if they are trying to use existing stacks.

   And the main message IMHO we should document:

   -> In the context of AMT the source-IP address of both reports
      and queries is irrelevant and if an implementation assigns
      any relevancy to them, then the AMT code has to avoid creating
      iconpatibilities.

c) Standards compliance
   
   I think compliance with IGMPV3/MLDv2 is really just an adjoint to
   b). If it wasn't for b), we could simply change the format of the
   membership/query messages however we like. WHich also means we shouldn't
   worry about this issue independent of b). In general i think we should
   document something like the following in the AMT spec:

   IGMPv3 addressing was derived from the assumption that there
   is an exsting L3-subnet addressing setup between querier and members,
   and the addresses where choosen accordingly. In the context of AMT,
   no such assumption exists. There is no globally unique IPv4 address
   assignment for the addresses inside the AMT tunnel, and there does
   not need to be any, because there is no unicast traffic forwarded
   via them.  

   To compromise between the wish of IGMPv3 to have some source
   addresses and these relaities, we use statically assigned
   IPv4-link-local-scope addresses, eg: global addresses that we re-use
   on every link: 154.17.1.1/2.

Cheers
    Toerless

---

From: Greg Bumgardner <[email-masked]>
Date: Wed, 11 Apr 2012 17:09:09 -0700

Toerless,

Comments below...

Thanks,

-g.b.

> requirement to IGMP and MLD.
I agree.
>     old receiver
I agree again. "MUST accept" is what we want.
>     not just accept the arbitrary address (both relay and gateway) ?
I am working on this at the moment. My plan is to test Windows, Mac and 
Linux handling of queries received via a tunnel interface. 
Unfortunately, I'm generating quite a few crashes in my testing.
>     able to use arbitrary existing IGMP stacks might not pan out afer all.
I was thinking one could simply set the tunnel I/F address to an address 
(e.g. .2) in the anycast prefix being used within the tunnel. 
Applications could bind to the interface with the appropriate address. 
Unless explicitly configured, the host should not be routing any packets 
sent to the relay discovery address (anycast prefix .1) - these would 
still be routed out the primary or other bound interface.

Unfortunately, this approach would not work in cases where anycast 
discovery is NOT used. Then we end up having to use some fixed addresses 
as discussed. This obviously complicates I/F management on the host.
>     with source-addersses if they are trying to use existing stacks.
Yep, this is the only approach that makes sense. Handling source 
addresses is an implementation detail for the recipients.
>        any relevancy to them, then the AMT code has to avoid creating
Yes.
>     on every link: 154.17.1.1/2.
A somewhat related topic is the handling of multicast joins for 
"non-routable" groups such as addresses in the IPv4 local network 
control block and IPv6 local scope addresses. I'm not sure whether this 
was addressed in earlier versions of the spec, but there's nothing in 
there now. Should we say anything about this? That the relay should 
ignore reports for these group addresses? Or does it really matter? It 
would complicate things to block these on the gateway side when embedded 
in IGMPv3/MLDv2 reports.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Apr 2012 17:30:49 -0700

> would complicate things to block these on the gateway side when embedded 

Well, you know from my long mails how i would like to see as
much as possible documented and ideally in RFCs and not only randomn
mailing list exchanges. Alas, the normal IETF process is to write
documents that foster coding creativity by usually leaving as much as
possible to the readers imagination and only specify whatever is necessary
to later on blame the implementer when his code is non-interoperable.

Meaning: process compliant would be not to write anything about this in
the AMT spec and let implementors figure out that a) there is no link-local
SSM scope in IPv4 so link-local scope in IPv4 is useless. b) even though one
can do link-lcal-scope SSM in IPv6, nobody ever defined any apps/services
that work via SSM (NTP, mDNS, any other service-discovery in link-local-scope).
So link local scope also sounds fairly unusable over IPv6 given how AMT is 
SSM only.  And then the implementor has to figure out whether to explicitly
filter joins for invalid SSM channels including link-local-scope, or whether
his implementation just wants to create that useless state because it's less
implementation work and it likely won't hurt anybody.

Cheers
    Toerless

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 12 Apr 2012 12:49:44 -0700

On Wed, 11 Apr 2012, Greg Bumgardner wrote:

-) A somewhat related topic is the handling of multicast joins for
-) "non-routable" groups such as addresses in the IPv4 local network control
-) block and IPv6 local scope addresses. I'm not sure whether this was addressed
-) in earlier versions of the spec, but there's nothing in there now. Should we
-) say anything about this? That the relay should ignore reports for these group
-) addresses? Or does it really matter? It would complicate things to block
-) these on the gateway side when embedded in IGMPv3/MLDv2 reports.

I suspect this would be much more trouble than it's worth.  No need to 
boil the ocean here.

Also, as to the larger issue of backward compatibility with earlier 
versions of the spec, I think this is much more germane to v4.  Given 
pragmatic considerations of v6 AMT at this moment in time (ie, probably 
won't need to remove socks and shoes bc you ran out of fingers counting up 
all the v6 AMT implementations out there today), IMO we shouldn't kill 
ourselves trying to achieve perfect backward compatibility for v6.