This is a IPv6 working group last call for comments on advancing the
following document as an Informational RFC:
Title : IPv6 for Some Second and Third Generation Cellular
Hosts
Author(s) : Jari Arkko, Peter Hedman, Gerben Kuijpers,
The last call for this document will end on May 27, 2002.
The Internet Area Directors requested shortening the working group last
call to allow time for the IESG to discuss the document to meet a 3GPP
deadline.
Bob
At 12:32 PM 5/17/2002, Bob Hinden wrote:
>This is a IPv6 working group last ca
> There is no need for MLD if the host only
> supports the well-known (hard coded in IPv6 implementations) link
> local multicast addresses. MLD is not used for listening on such
> addresses.
>==> s/link local/link-local/
actually, even for these well-kno
> > There is no need for MLD if the
> host only
> > supports the well-known (hard coded in IPv6
> implementations) link
> > local multicast addresses. MLD is not used for listening on such
> > addresses.
> >==> s/link local/link-local/
>
>
> A few comments.
>
> 2.2 RFC2373 - IP Version 6 Addressing Architecture
>
>The IPv6 Addressing Architecture [RFC-2373] is a
> mandatory part of
>IPv6. Currently, this specification is being updated by
>[ADDRARCHv3]; therefore, this specification may be
On Wed, 22 May 2002, Hesham Soliman (ERA) wrote:
> => RFC 2460 has some text on this, anticipating SIIT.
> I actually had the same thoughts (as you), but was
> told about this praragraph in 2460.
Time to raise the question here then..
> > ==> Bad wording: "may be supported ... if ..."? Of co
Hesham,
"Hesham Soliman (ERA)" wrote:
>
> Itojun,
>
> > >=> I've never seen that in any spec.
> > >I guess you are saying that it's needed for L2
> > >switches that snoop MLD messages to decide
> > >on mcast forwarding of mcast ethernet frames?
> > >
> > >If so, then we don't have t
Brian
>
> Take a look at the very last paragraph of section 5 of 2710. It
> states:
>
> MLD messages ARE sent for multicast addresses whose scope is 2
> (link-local), including Solicited-Node multicast
> addresses [ADDR-
> ARCH], except for the link-scope, all-nod
Hesham,
"Hesham Soliman (ERA)" wrote:
>
>incoming packet to ff02::blah
> |
>H2R--- H1
>
> If only H2 joined, doyou assume that the router will
> send it to H1 as well? Why?
> Note H1 and H2 do not share the same link.
Let me clarify my comment. ff02::blah is a bad example for what I
am asking. Will the 3G network support applications utilizing mcast?
Will a host be able to join ff05::abcd and receive data on that group
address? If that is supported, then MLD is needed.
Brian
Brian Haberman wrote:
>
> Hesh
Brian,
That's exactly what the draft says.
Hesham
> Let me clarify my comment. ff02::blah is a bad example for what I
> am asking. Will the 3G network support applications
> utilizing mcast?
> Will a host be able to join ff05::abcd and receive data on
> that group
> address?
Hi All,
I have several comments on this document, all offered as an
individual WG member (not as a WG co-chair).
Although I understand that the 3GPP would like us to complete
this document quickly, I still have some significant issues with
this document. I know that there is some resistance t
> First, I'll deal with the technical/content issues:
>
> (1) I think that this document should explicitly state, in the
> introduction, that it is not a standard and is not intended to
> modify or contradict any IPv6 standard documents. I thought that
> we had agreed to something
> Now, for the editorial issues:
>
> (5) In section "1 Introduction", the only paragraph is not
> properly laid out -- not clear if it is meant to be one or
> two paragraphs.
>
> (6) The document states:
>
> "Cellular hosts should not support configured or
> automa
Hello folks,
> > There is a portion of mobility -- I believe that is is called the
> > "correspondent node option", or something like that -- that must be
> > implemented in all IPv6 hosts, in order to allow optimal routing
> > to mobile nodes that are away from their home networks.
>
Hi Margaret,
> (1) I think that this document should explicitly state, in the
> introduction, that it is not a standard and is not intended to
> modify or contradict any IPv6 standard documents. I thought that
> we had agreed to something like this earlier.
Yes, we had agreed this and we e
Charlie,
> 8.1. Requirements for All IPv6 Hosts and Routers
>
>Since any IPv6 node may at any time be a correspondent node of a
>mobile node, either sending a packet to a mobile node or receiving
a
>packet from a mobile node, the following requirements apply to ALL
>IPv6 nodes (wh
> > (1) I think that this document should explicitly state, in the
> > introduction, that it is not a standard and is not intended to
> > modify or contradict any IPv6 standard documents. I thought that
> > we had agreed to something like this earlier.
>
>Yes, we had agreed this and we even had
Margaret Wasserman wrote:
>
>>>(1) I think that this document should explicitly state, in the
>>>introduction, that it is not a standard and is not intended to
>>>modify or contradict any IPv6 standard documents. I thought that
>>>we had agreed to something like this earlier.
>>>
>>Yes, we had
Pekka Savola wrote:
>>In any case, communications with e.g. old IPv6 nodes that do not yet
>>support MIPv6 are always possible without any other problems than
>>non-optimal routing.
>
> Are you sure these are the only problems? It seems to me, that these old
> IPv6 nodes's, ie. no support for
Hi Margaret,
My 2 cents:
> (1) I think that this document should explicitly state, in the
> introduction, that it is not a standard and is not intended to
> modify or contradict any IPv6 standard documents. I thought that
> we had agreed to something like this earlier.
It does specifically st
Title: RE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third Generation Cellular Hosts"
> >
> > "4. Mobility
> >
Is there support in this WG for making route optimization a MUST in all IPv6 hosts ? The ball is really in this WG's court
>
>In 3GPP, the SGSN keeps track of the status of the GGSN and will inform
>hosts if their GGSN went down. The 'keeps track' mechanism involves an IP packet
>exchange, so in order for the SGSN to think that the GGSN is up, the GGSN
>must be responding at layer 3. If the GGSN is up but not forward
Hi Margaret,
> In this case, the intended audience of the document primarily lies outside of the
> IETF. Do you think that they will really understand the difference between our
> different document types?
I think you should give a little credit to folks - I do think they understand
the IETF d
> > (1) I think that this document should explicitly state, in the
> > introduction, that it is not a standard and is not intended to
> > modify or contradict any IPv6 standard documents. I thought that
> > we had agreed to something like this earlier.
> Yes, we had agreed this and we even h
Margaret Wasserman wrote:
>>In 3GPP, the SGSN keeps track of the status of the GGSN and will inform
>>hosts if their GGSN went down. The 'keeps track' mechanism involves an IP packet
>>exchange, so in order for the SGSN to think that the GGSN is up, the GGSN
>>must be responding at layer 3. If th
Hi Margaret,
> (1) I think that this document should explicitly state, in the
> introduction, that it is not a standard and is not intended to
> modify or contradict any IPv6 standard documents. I thought that
> we had agreed to something like this earlier.
Yes, we had agreed this and we ev
en [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 17, 2002 1:50 PM
To: [EMAIL PROTECTED]
Subject: UPDATE: IPv6 w.g. Last Call on "IPv6 for Some Second and Third
Generation Cellular Hosts"
The last call for this document will end on May 27, 2002.
The Internet Area Directors requested shorteni
>The last call for this document will end on May 27, 2002.
>
>The Internet Area Directors requested shortening the working group last
>call to allow time for the IESG to discuss the document to meet a 3GPP
>deadline.
not objecting to this particular change, but is it usual thing to
Hi Hani,
> I noticed that robust header compression requirements are missing from the
> "IPv6 for cellular hosts" draft. Should a section be added highlighting its
> importance and recommending its support (as a should requirement maybe)?
The authors discussed this early on, and as there are n
Note: folk might want change some subject lines to aid followups on
the thread...
Margaret Wasserman <[EMAIL PROTECTED]> writes:
> (4) The document states:
> "4. Mobility
>
> For the purposes of this document, IP mobility is not relevant. When
> Mobile IPv6 specification is appr
>
>There is a basic problem with having this document specify any sort of
>required behavior with respect to MIPv6. There is no RFC today for
>MIPv6 (we are getting close, but we are not quite there yet).
Okay. I agree, then, that we shouldn't specify any MIP behaviour in this
document. I was
32 matches
Mail list logo
