On 2012-06-04 22:13, Jacni Qin wrote:
Section 6.1 introduces IGMP/MLD translation, but I fear it is very
underspecified. Our own effort at specifying IGMP/MLD translation is
in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite
multicast would be better served by referencing our draft instead.
Thanks for your comments, while as stated in the text, the Interworking
function is a combination of proxying (RFC4605) and translation
(draft-ietf-mboned-64-multicast-address-format, sorry the reference was
lost, we'll fix it).
I understand that. But note that this is an important new function.
AFAIK IGMP/MLD translation doesn't exist in any other RFC. Your draft
would be underspecifying it IMHO, possibly leading to interoperability
issues.
I don't think it's up to SOFTWIRE to standardize IGMP/MLD translation.
The implementations vary, and we are trying to avoid deeply diving into
that since it is sufficient for the implementers, and those should be
detailed in some deployment document if needed. Anyway, please list what
you think is missing, we can add more text to further clarify it. Thanks
a lot!
At IETF 83 I showed this list to the PIM working group to demonstrate
that IGMP/MLD translation is not as simple as people think it is. It's a
list of things our draft (draft-perreault-mboned-igmp-mld-translation)
specifies:
- Well-known multicast address equivalences between IPv4 and IPv6.
- Message type equivalences between IGMPv{1,2,3} and MLDv{1,2}.
- Translation needs to be performed logically on upstream interface of
proxy so as not to mess with Querier elections.
- Router Alert
- IPv4 option ↔ Hop-by-Hop IPv6 extension header
- Send on output IFF it was received on input.
- Set value to zero unconditionally.
- Reports with unspecified source address need to be handled differently
for IGMP vs MLD.
- Allocation of a “Translated” bit in IGMPv3 and MLDv2 Queries and Reports.
- Formulas for the conversion of MRD↔MRT with or without loss of precision.
- Preservation of Additional and Auxiliary Data.
- MTU considerations... sigh
- Data plane handled according to RFC6145.
I don't want to argue this list in SOFTWIRE because I think it's the
wrong forum. My point is that IGMP/MLD translation needs to be correctly
specified, and it needs to be done in PIM. Any SOFTWIRE protocol that
requires IGMP/MLD translation needs to refer to something coming from PIM.
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
