Subject: Re: [multimob] Comments on draft-ietf-multimob-pmipv6-base-solution-01.txt

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 28 May 2010 07:54:17 -0700 (PDT)

Thomas,

Regarding the tunnel convergence problem, let's define it like:

Tunnel convergence  
occurs when different MNs 
connected to the same MAG belong to different LMA. Then if they 
subscribe to the same multicast group, multicast data from several 
LMAs are replicated at the MAG to MNs and thus MN receives duplicate multicast data.

and then clarify if MN receives duplicate data packets if not why?

>> [behcet] Add here one paragraph on NAT 
> issue and a reference to RFC 5135
> 
> What is the NAT 
> issue?
> 

> I've responded to the NAT topic a while ago: actually, 
> there are no NAT issues within the PMIP domain, as PMIP does not support a NAT 
> on the MAG. NAT issues may arrive outside the PMIP domain, but that is beyond 
> the scope of the document.

> So, all one could say in the draft is: There 
> are no NAT issues, but this is already stated in RFC 5213.

What do you mean there are no NAT issues? 
IGMP uses source (public or private) IPv4 addresses unlike MLD which uses link local and NAT changes the source address and port number. What are the implications of that?
RFC 5135 recommends IGMP Proxy to be placed at the NAT device. What are the implications of this for the draft? 
Also requirements stated in RFC 5135?

RFC 5844 assumes:
A deployment where a mobile access gateway uses an IPv4 private
      address with NAT [RFC3022] translation devices in the path to a
      local mobility anchor is not supported by this specification.

I don't think this precludes NAT at the MAG.

Regards,

Behcet

---

From: Stig Venaas <[email-masked]>
Date: Fri, 28 May 2010 08:49:12 -0700

> and then clarify if MN receives duplicate data packets if not why?

I think it's good to clarify this.

>> are no NAT issues, but this is already stated in RFC 5213.

I don't think it is an issue either, unless we expect NAT to be
deployed in this scenario. Do we?

> Also requirements stated in RFC 5135?

There are of course some issues with deploying NAT, but nothing
particular to this solution.

Anyway, here is what happens if NAT is used at the proxy. Usually
multicast addresses are not changed, just unicast addresses. For
IGMP/MLD reports it is not a problem since you are doing proxying.
The proxy receives reports with say private IPv4 addresses, and then
the proxy sends its own IGMP report based on the aggregate state, using
its public address. This is exactly as when NAT is not used though.

For any multicast received from the outside, you would usually not do
any translation. So NAT does not have much impact. But I don't think we
should discuss this unless we think NAT will be deployed together with
this solution.

Stig

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

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 29 May 2010 00:54:44 +0200

Hi Behcet,

> LMAs are replicated at the MAG to MNs and thus MN receives duplicate multicast data.

I'm not exactly sure what you're heading at, here: the traditional 
"tunnel convergence problem" is from MIPv4 when multiple (many) 
identical data arrive in tunnels at a foreign agent.

The corresponding picture in PMIPv6 is that data arrives in multiple 
tunnels at the MAG (from different LMAs). In 
draft-ietf-multimob-pmipv6-base-solution duplicate data do not arrive at 
an MN because of the PtP link model: A MAG will sort LMA -> MAG tunnels 
to individual downlinks and no MN will receive data from different LMAs. 
The discussion in Appendix C is only on scaling efficiency at LMA, MAG 
and the network in between these agents.

> and then clarify if MN receives duplicate data packets if not why?

Yes, see above: we will stress this in the draft.

> What do you mean there are no NAT issues?

I guess the NAT-things have been discussed. This is really not a subject 
of an "inner" PMIPv6 domain, even though I agree that many providers use 
NATs (at their edges). They are "invisible" though to an internal 
mobility management.

Best regards,

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 29 May 2010 11:14:55 +0200

Hi Stig,

> I think it's good to clarify this.

Yes, we'll do.

>>> What is the NAT issue?
>>> I've responded to the NAT topic a while ago: actually, there are no
>>> NAT issues within the PMIP domain, as PMIP does not support a NAT on
>>> the MAG. NAT issues may arrive outside the PMIP domain, but that is
>>> beyond the scope of the document.
>>
>>> So, all one could say in the draft is: There are no NAT issues, but
>>> this is already stated in RFC 5213.
>
>> What do you mean there are no NAT issues? IGMP uses source (public or
>> private) IPv4 addresses unlike MLD which uses link local and NAT
>> changes the source address and port number. What are the implications
>> of that?
>> RFC 5135 recommends IGMP Proxy to be placed at the NAT device. What
>> are the implications of this for the draft? Also requirements stated
>> in RFC 5135?
>

As quoted earlier: RFCs 5213/5844 explicitly exclude scenarios with a 
NAT deployed on MAGs. So I don't think we need to provide a discussion 
on NATs at the MAG, since we clearly stick to the set up defined in RFCs 
5213/5844.

Best wishes,

Thomas

--