Subject: Re: (ngtrans) Review of draft-ietf-ngtrans-mtp-01.txt

From: Kazuaki Tsuchiya <[email-masked]>
Date: Tue, 25 Jun 2002 21:46:03 +0900

Dear Brian

I must make a sincere apology to you.
I had to answer the following comments more quickly.

At 22:54 02/04/30 +0900, you wrote:
>The following are comments on draft-ietf-ngtrans-mtp-01.txt.  I
>apologize for not getting them to the list sooner.
>
>      1. The discussion of MTP talks about header translation, but
>         does not discuss the use of ALGs to handle multicast apps
>         that include IP addresses in the application layer.  Those
>         addresses may be unicast or multicast.  How will MTP deal
>         with those?

I will rewrite 6.2 (1) as follows. Is this not enough?
----------------------------------------------------------------------
6.2 Limitations
     (1) Applications
        In common with [NAT] and [NAT-PT], IP conversion needs to trans-
        late IP addresses embedded in application layer protocols. So
        MTP needs ALGs for their translation.
----------------------------------------------------------------------

>      2. Has anyone done an analysis on how the translations will
>         affect RTP/RTCP feedback?

Sorry, I cannot make me clear yet. I need more investigation.
Would you give me a grace?

>      3. This draft needs some more work on fragment handling.
>         Will an MTP node perform fragment re-assembly on the
>         packets before doing the translation?

Fragment handling in MTP is same as that in NAT-PT.
I will add the following into the draft.
----------------------------------------------------------------------
5. Protocol Translation Details
     Protocol Translation Details described in [NAT-PT], including
     TCP/UDP/ICMP Checksum Update, are associated to MTP. See [NAT-PT].
----------------------------------------------------------------------

>      4. Section 3.1 and 3.2 talk about an administrator doing
>         configuration prior to a multicast data flow.  How
>         will that work if the applications being used are
>         learning the multicast address from SDR? webpages?
>         DNS?
>
>      5. If the MTP node needs an administrator to do config before
>         it can translate, who will notify the receivers as to what
>         multicast address to join?

I will explain a case of communication from an IPv4 Sender to IPv6
Receivers. MTP works just like one of IPv4 Receivers, and MTP also
works just like an IPv6 Sender.

MTP can know IPv4 multicast addresses available as one of IPv4
Receivers. For example, MTP obtains IPv4 multicast addresses
available via an IPv4 SAP (an IPv4 SDR). MTP shows the IPv4
multicast addresses and the corresponding IPv6 multicast addresses
on its web. An IPv6 Receiver looks at its web and presses a button
for joining in a group. MTP registers the IPv4 multicast address,
the IPv6 multicast address, and the IPv6 Receiver address, into a
table. When there is yet no member to the group, MTP carries out
configuration for translation.

>      6. In section 4 there needs to be more concrete definitions.
>         How does the MTP node know if an address is "well-known"?
>         Does it keep a static list so it knows how to set 'x'?

Yes, MTP needs a list of "well-known" addresses.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 26 Jun 2002 08:19:19 -0400

Comments in-line...

> I will rewrite 6.2 (1) as follows. Is this not enough?

OK.

> Would you give me a grace?

Yes.  This topic needs to be investigated.

> I will add the following into the draft.

OK.

> configuration for translation.

I am not as concerned with how MTP learns of the addresses, rather
how do the clients learn of the addresses?  MTP can get addresses
from SDR, but how does a client on the other side of the MTP node
know what addresses to join?  Does MTP issue SDR messages?  How
will MTP work in the presence of SSM services where the source and
group addresses are coming from webpages?

> Yes, MTP needs a list of "well-known" addresses.

Then MTP implementations must be configurable for this list.  And
operators must be aware of the list of "well-known" addresses.

Brian