[EMAIL PROTECTED] writes:
> 2. Packet filtering
> A stateless filter cannot test the lowest address bits, because
> being stateless it does not know which suffices are in use at any
> moment.
What do you mean by a stateless filter?
> Previously the stateless filter could limit subnet address
>
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
I am new to IPv6. Forgive me if my query is too naive.
Is there any zone concept in IPv6 Addressing Architecture??
Can a packet with link local address as source address traverse
beyond link. ( Would the router in that link drop the packet??)
Is there any difference between organisation local
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
At Tue, 14 May 2002 20:19:32 -0400, Steve Bellovin wrote:
>
> >So how can we understand the threat model for DNS discovery?
> >
> That takes work... A good starting point would be Derek Atkins' and
> Rob Austein's DNS threat analysis document
> (draft-ietf-dnsext-dns-threats-01.txt) I haven't ha
>
>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
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
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 22, 2002 4:30 AM
> To: [EMAIL PROTECTED]
> Subject: Re: IPv6 w.g. Last Call on "IPv6 for Some Second and Third
Genera
> tion Cellular Hosts"
>
> >=> I've never seen that in any spec.
> >I gues
Hi Glenn,
> > "4. Mobility
> >
> Is there support in this WG for making route optimization a MUST in all IPv6
hosts ?
I agree. I don't think it the "IPv6 for Some Second and Third Generation
Cellular Hosts"
documents place to recommend behavior
> > (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
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
>
>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,
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. This is really a "do you really want ubiquito
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
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> >=> Do you mean that MLD is used for the ALL Nodes mcast
> >address ofr example?
>
> yes.
>
> itojun
No.
RFC 2710 end of section 5:
The link-scope all-nodes address (FF02::1) is handled as a special
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
On Wed, 22 May 2002, Jari Arkko wrote:
> I do agree about the correspondent node functionality part, though. However,
> there's a couple of things we should observe. In the current design,
> correspondent nodes do not need do anything special unless they want to
> do Route Optimization. The exact
A new version of "IPv6 Node Information Queries" was published recently.
Title : IPv6 Node Information Queries
Author(s) : M. Crawford
Filename: draft-ietf-ipngwg-icmp-name-lookups-09.txt
Pages : 15
Date: 20-May
> > (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
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
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
I assume, this discussion is in relation
to the draft?
I'm updating the text right now, so please let me
know what you want to add. Specifically any ill-advice
that the draft is giving to implementers.
Hesham
> -Original Message-
> From: Randy Bush [mailto:[EMAIL PROTECTED]]
>
> How about if we find ways to say: IETF does not see the need to
> encode these practices, for whatever access technology, in RFCs?
^ ^
| |
| `-- ill-advised
|
`-- or assist in any way
randy, channeling keith
--
> > Then he will get the service from the
> > corporate network.
>
> heck, i may run a full cacher on my 3gpp device
>
> > BTW, almost all servers support recursive queries
> > anyway.
>
> don't count on it
=> I'm not, the text merely says that things
will work better if th
> > How could 3GPP require/enforce this? What if a 3GPP user configures a
> > 3GPP host to use a DNS server within his corporate network, for example?
>
> bingo! my intended use of gprs/3gpp/... is layer three connectivity.
> i use my own dns servers, smtp servers, ... doesn't everybody?
>
>
> Then he will get the service from the
> corporate network.
heck, i may run a full cacher on my 3gpp device
> BTW, almost all servers support recursive queries
> anyway.
don't count on it
randy
IETF IPng Working Group Maili
> How could 3GPP require/enforce this? What if a 3GPP user configures a
> 3GPP host to use a DNS server within his corporate network, for example?
bingo! my intended use of gprs/3gpp/... is layer three connectivity.
i use my own dns servers, smtp servers, ... doesn't everybody?
randy
> At 07:05 AM 5/22/02 , Hesham Soliman (ERA) wrote:
> > > ==> I completely agree, but this requires the servers
> > > support (or rather:
> > > haven't disabled the support for) recursive queries. I
> > > guess this only
> > > depends on the network topology. If DNS se
At 07:05 AM 5/22/02 , Hesham Soliman (ERA) wrote:
> > ==> I completely agree, but this requires the servers
> > support (or rather:
> > haven't disabled the support for) recursive queries. I
> > guess this only
> > depends on the network topology. If DNS servers are managed by the
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.
>
> 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
> 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
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
On Wed, 22 May 2002, Pekka Savola and Hesham Soliman (ERA) wrote:
<...>
>>Actually, as a side
>> node, I think 2462 should be deprecated and replaced by
>> 3041please don't shoot!
>
>Where did I put my M16. ;-)
>
>In the meantime, you might want to check out
>draft-dupont-ipv6-rfc3041har
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?
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
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.
sorry, i was wrong about ff02::1.
>=> But do you assume that the default router on a p2p link
>will forward mcast packets to multiple links even though
>hosts on those links didn't join this group?
> incoming packet to ff02::blah
> |
> no, it doesn't make sense to me. even for hardcoded
> addresses, there
> should be an MLD join packet issued from the listener.
=> Well, the MLD spec doesn't say that though! We can change
the MLD spec if enough people agree, but as far as this
draft is concerned,we have to fo
On Wed, 22 May 2002, Hesham Soliman (ERA) wrote:
> > 3041 isn't really all that beneficial if IID part is
> > already quite random
> > (and is changing from time to time, e.g. in the scope of a
> > day or week).
>
> => Agreed, but unfortunately it is left up to implementations,
> so ho
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
>So when is MLD needed? I will copy a paragraph from
>the intro of 2710:
>
> "The purpose of Multicast Listener Discovery (MLD) is to enable each
> IPv6 router to discover the presence of multicast listeners (that is,
>
>
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
> >
> > => The IID part for link-local addresses is essentially
> > a random number.
>
> Ok, this is what I really was after. Whether it could be
> generated from
> some contract number, or whatever.
>
> >There is nothing in 3GPP that specifies
> > how it should be ge
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 this situation in
> >cellular networks. What we're deali
On Wed, 22 May 2002, Hesham Soliman (ERA) wrote:
> > > > is), changing the prefix doesn't help with privacy.
> > >
> > > => The IID for the _link-local_address_only.
> > > The host can use any other IIDs for addresses
> > > with scopes larger than the link-local one.
> > > No securi
>=> 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 this situation in
>cellular networks. What we're dealing with is
>a p2p link with no multic
>
> > > The GGSN always provides an Interface
> Identifier to
> > >the mobile host.
> > >
> > > ==> Is that IID trackable? If so, this might be
> worth mentioning in
> > > security considerations' second "bullet": If IID is
> > > trackable (like
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
> >=> Do you mean that MLD is used for the ALL Nodes mcast
> >address ofr example?
>
> yes.
=> 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 do
>=> Do you mean that MLD is used for the ALL Nodes mcast
>address ofr example?
yes.
itojun
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive:
> 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
> > 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/
>
>
> 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
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 made obsolete by
the new one,
56 matches
Mail list logo
