Thanks for your comments, response inline.
Jun-ichiro itojun Hagino wrote:
>
> >> A new draft on IPv6 Cellular hosts requirements was submitted today.
> >> Until it's announced, you can view it here:
> >> http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cellular-host-00.txt
> >> I'm doing this for Jari (one of the author) as he's away.
>
> here are a couple of comments.
>
> itojun
>
> 2.1 RFC1981 - Path MTU Discovery for IP Version 6
>
> > If Path MTU Discovery is not implemented, then the uplink packet
> > size MUST be limited to 1280 octets (standard limit in [IPv6]).
> > However, the cellular host MUST be able to receive packets with size
> > up to the link MTU.
>
> The text (3rd and 4th line) is unclear (is it after the reassembly
> or before? or am I badly confused?), and may conflict with RFC2460
> depending on the link MTU for the cellular host. ???
>
> RFC2460 page 25
> > A node must be able to accept a fragmented packet that, after
> > reassembly, is as large as 1500 octets. A node is permitted to
> > accept fragmented packets that reassemble to more than 1500 octets.
> > An upper-layer protocol or application that depends on IPv6
> > fragmentation to send packets larger than the MTU of a path should
> > not send packets larger than 1500 octets unless it has assurance that
> > the destination is capable of reassembling packets of that larger
> > size.
This is before reassembly. Let's try to clarify this with an example. Consider
the following situation:
link MTU=1500 path MTU=1500
cellular host A <--------------> router <--- ... network ... ---> host B
The cellular host A communicates with host B. Host A does not do Path MTU
discovery, but host B does. Host A will have to limit its packet size to 1280
bytes, while host B finds a path MTU of 1500 and will send packets up to that
size. Maybe its a bit unclear, since we're stating the obvious that a host must
be able to receive packets with size up to its link MTU.
>
> 2.10 RFC2710 - Multicast Listener Discovery (MLD) for IPv6
>
> (MLD6 is SHOULD) what happens if a cellular node doesn't emit MLD?
> will the upstream router always flood multicast datagrams to cellular
> hosts?
>
A cellular host that wants to join multicast groups with a scope larger than
link-scope will have to notify the upstream router in some way. Probably MLD is
the best way to do this. When no notification is sent to the upstream router,
you're right, flooding is the only option, but not preferable.
The typical topology at IP layer for a cellular network (such as 3GPP) is as
follows:
Internet
|
|
|
___________|__________
| |
| Upstream router |
|______________________|
| | ....... |
| | |
| | |
host 1 host 2 host n
A large number of cellular hosts each have a point-to-point link to an IP router
that is part of the cellular network and acts as a gateway to the Internet for
the cellular system. The point-to-point link between the router and a cellular
host typically consist of multiple links at link-layer, including a wireless
link closest to the cellular host. Flooding will be a very inefficient for
multicast datagrams (in fact it will be a broadcast then), since a single
subscribed host could cause broadcasting of datagrams to 1000s of hosts.
For such a topology, the advantages of using multicasting (including MLD) might
be limited. A multicast datagram arriving at the router will have to be sent on
each individual point-to-point link to each cellular host subscribed to that
particular multicast group. Only the load on the link from the router to the
Internet can be reduced by multicasting. This at cost of extra load on the
(bandwidth limited) wireless links in the form of MLD signaling.
> 2.11 RFC2711 - IPv6 Router Alert Option
>
> in 2.4, it is specified that a cellular host will not be come a router.
> therefore, there should be no need to implement the receiver side
> of the router alert option,
Good point, we'll note that.
Gerben Kuijpers
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
