Pekka,
>On Mon, 4 Mar 2002, Atsushi Inoue wrote:
>> >A few comments in addition to ones I sent for -00..
>> >
>> > Table 1. Resource restrictions of LCNA
>> >
>> > ===+===+==+===
>> > Memory CPU Performance
Erik Nordmark wrote:
>>If there are decisions as to what to do with ND/DAD/whatever,
>>should those be made by (a) IPv6 WG, (b) 3GPP, or (c)
>>vendors?
>>
>
> Jari,
>
> I think the ND/DAD type issues can be dealt with by the IPv6 over foo
> document which should be a lot quicker to produce than
Pekka,
Sorry not respond quickly.
I answer some part of your questions.
Inoue-san will answer the rest of them.
From: Pekka Savola <[EMAIL PROTECTED]>
Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt
Date: Mon, 4 Mar 2002 17:08:18 +0200 (EET)
> > >3.1.3 Fragment Header
> > >
> > >
From: Pekka Savola <[EMAIL PROTECTED]>
Subject: Re: Should connecting to the Internet be Optional? (Half-serious!)
Date: Tue, 5 Mar 2002 10:30:55 +0200 (EET)
> On Mon, 4 Mar 2002, Tony Hain wrote:
>
> (Half-) seriously.. I think connecting to the Internet MAY be optional.
>
> I discussed in lcn
FIELD,GEOFF wrote:
> ...
> What about the situation where a terminal is in a fast-
> moving vehicle (a car on a highway, a train, an aircraft)?
> Does each and every handover have to have ND added to
> it as well as all the other stuff that's going on? It's
> a thorny issue, particularly for a ha
I don't think I've popped up here before, but I've been
following the conversations for a while.
I'm currently working in the 3G field, so I'd just like
to present my view on the matter.
Just a gentle reminder or two first:
Cellular phones - 3G or otherwise - tend to be *mobile*.
People use them
>Now, my concern is this:
>how long do you think producing the general document
>to an RFC will take? What should we say in the
>meantime to folks who want to deploy IPv6 now?
>If there are decisions as to what to do with ND/DAD/whatever,
>should those be made by (a) IPv6 WG, (b) 3GPP, or (c)
>ve
> I also think that we should start work on two standards-track
> documents, both of which would use the current draft as
> input:
>
> - An "IPv6 over " document for 3GPP links.
> - A general "IPv6 Node Requirements" document.
I think the above two documents make a lot of sense.
> This special router is called a GGSN and it knows it MUST NOT configure
> itself with a unicast address on that prefix. That means there's no
> conflict. Does that make sense?
What about a link-local address? Those are required on all interfaces.
And the RAs sent by the GGSN must have a link-lo
> If there are decisions as to what to do with ND/DAD/whatever,
> should those be made by (a) IPv6 WG, (b) 3GPP, or (c)
> vendors?
Jari,
I think the ND/DAD type issues can be dealt with by the IPv6 over foo
document which should be a lot quicker to produce than the host requirements
document.
> No. The terminal (phone) doesn't need to act as a router to allow
> for multiple devices behind it to connect to the cellular interface.
> You could eventually have multiple serial connections to the terminal
> each having its own corresponding air interface connection. So it can
> act as a host
Hi Jari,
>I think most of
>us agree that a host requirements document is
>something that we should have and is a necessary
>one. If we had a general document I'm pretty sure
>there'd be no need for any specific XXX host
>requirements documents.
I hope that we do have agreement about this. Are
Kunapareddy R B wrote:
> Hi all,
>
> I am new to this group. I might be asking simple questions. Can
> u
> clarify the following.
>
> *. Router Can be configured automatically as part of
> Autoconfiguration.
>
> *. How can One ensure the autoconfiguration address must be
> Global Ad
Vinayak Prabhu wrote:
> Can a node have multiple link local addresses?
There is nothing to prevent a node from having multiple link local
addresses, but what would be the value? The only thing it would appear
to do is consume resources on the node that has multiple addresses, and
require all othe
Hi John,
>I am having a hard time understanding what your objections
>to the document are. You have raised some good technical
>points & we are looking at how to address them & revise
>the document. However, you seem to be saying now that the
>technical issues are not important.
I don't belie
Michael Thomas wrote:
> [EMAIL PROTECTED] writes:
> > Just to add onto Jari - it would be a no-brainer to
> > state that IPsec (AH & ESP) MUST be supported,
> > IKE MAY/SHOULD be supported. However, does this
> > give users anything? Will it increase security for
> > these devices, or is i
> > > This seems to presume that you can predict in advance all of the
> > > applications that a user will wish to execute on a particular node. Can you
> > > do that?
> >
> > On a workstation you can't. On a tiny cellular device you
> > often can.
> only if the device doesn't have a data port.
>> [Please note that I actually think that we should be able to
>> disable DAD for some link types. I made a proposal to that effect
>> several years ago, but my arguments didn't win the day.]
>Yes.
>RFC-2462, "5.1. Node Configuration Variables":
> DupAddrDetectTransmits = 0
> => DAD is di
Hi,
Can a node have multiple link local
addresses?
Regards,
Vinu
Karim El-Malki wrote:
> This special router is called a GGSN and it knows it MUST NOT
> configure
> itself with a unicast address on that prefix. That means there's no
> conflict. Does that make sense?
I will grant you that I don't know (or want to know) the inner workings
of a GGSN, but what is
[EMAIL PROTECTED] writes:
> Just to add onto Jari - it would be a no-brainer to
> state that IPsec (AH & ESP) MUST be supported,
> IKE MAY/SHOULD be supported. However, does this
> give users anything? Will it increase security for
> these devices, or is it just something that will make
>
Title: Prefix Delegation Option in RA - draft comments
Hi,
I have just read your draft that proposes to add a new Prefix Delegation Option to Router Advertisement so as to enable configuration of a site router (I'm using you definition of a site router).
Here's my comments :
3.1 Deployemen
[EMAIL PROTECTED] wrote:
> Hi Margaret,
>
> > Before folks go and do a lot of additional work to update
> > draft-ietf-ipv6-cellular-host-00.txt based on our discussions,
> > I think we have to answer a fundamental question:
>
> I am having a hard time understanding what your objections
> to the d
Hello,
Disclaimer: I am not fully caught up on this discussion.
I hope that cellular hosts would be able to run DAD and ND
whenever they need to. I would hope that the IETF would
not approve a document that says "some" IPv6 hosts MUST NOT
(or even SHOULD NOT!) implement DAD/ND. This would be
John,
I don't think there is problem with the content. I believe
the content needs to be separated. One part to discuss IPv6
operation over cellular links and one part to discuss the minimal
IPv6 functionality for hosts. The second part really belongs in
a general host requirements documen
Jari Arkko wrote:
> how long do you think producing the general document
> to an RFC will take? What should we say in the
> meantime to folks who want to deploy IPv6 now?
What if we make some revision to "draft-ietf-ipv6-cellular-host",
and run that as Informational? Then we could have IPv6 Hos
John,
Since I have already voiced an agreement with Margaret's
suggestion, let me explain my rationale. Your document is a
mix of:
1. Host requirements (granted they are limited functionality hosts)
2. IPv6 over cellular links requirements
I believe that #2 is important as a stan
John,
I think some 90% of the new cellphones, even low end, now have Java on
them. Carriers like it.
But the last spec I saw for the Java MidP (the Java profile that runs on
a cell phone) did not have
a way to open a socket. You could only go through a URL. That may have
changed. So I think it is
Margaret,
You had the below proposal:
> I also think that we should start work on two standards-track
> documents, both of which would use the current draft as
> input:
>
> - An "IPv6 over " document for 3GPP links.
> - A general "IPv6 Node Requirements" document.
I would very much like to h
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 05, 2002 12:42 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt
>
>
> Hi Phil,
>
> There will be m
> Karim El-Malki wrote:
> > No, the router doesn't allocate any addresses on the
> > "delegated" prefix.
> > That was the assumption behind our 3gpp-advice draft and has
> > been followed
> > by 3gpp.
>
> The router has to allocate at least 1 address in the prefix,
> even if it
> is ju
> >It won't because a cellular host /e.g. 3gpp) is alone on its link.
>
> On a point-to-point link, there must be at least two nodes...
> In this case, one node is the cellular host and the other is
> the 3GPP router (GGSN).
>
> The link is the PDP Context. If more than one host is attached
> v
Hi Phil,
> > I don't think we should. It just starts us down that
> > slippery slope of creating new "foo hosts" requirements docs.
> > Your following arguments are reason enough to avoid this path.
>
> Agree we shouldn't.
If the discussion is that creating hosts requirements for every kind
Brian,
> I don't think we should. It just starts us down that slippery slope
> of creating new "foo hosts" requirements docs. Your following
> arguments are reason enough to avoid this path.
Is your complaint that the document is Minimum IPv6 Requirements for
a Cellular Hosts? Are there probl
Hi Phil,
> > > BTW: Does 1) include the ability to run e.g. Java applets or
> > > other downloadable code?
> >
> > I think we would clasify it as closed, no applets or
> > downloadable code.
>
> Hmmm. I think you've excluded a large number (the majority) of the
> kinds of devices that you'd
Hi Phil,
> As others have pointed out it's hard to be more ambiguous than this.
> What is a terminal?
>
> There is this in the abbreviations section:
>
> "TE Terminal Equipment. For example, a laptop attached
>through a 3GPP handset."
TE is actually something quite d
Hi Margaret,
> Before folks go and do a lot of additional work to update
> draft-ietf-ipv6-cellular-host-00.txt based on our discussions,
> I think we have to answer a fundamental question:
I am having a hard time understanding what your objections
to the document are. You have raised some good
Margaret Wasserman wrote:
> Before folks go and do a lot of additional work to update
> draft-ietf-ipv6-cellular-host-00.txt based on our discussions,
> I think we have to answer a fundamental question:
>
> Should the WG publish an informational RFC detailing the IPv6
> requirements for cellular h
Karim El-Malki wrote:
> No, the router doesn't allocate any addresses on the
> "delegated" prefix.
> That was the assumption behind our 3gpp-advice draft and has
> been followed
> by 3gpp.
The router has to allocate at least 1 address in the prefix, even if it
is just the all-routers address. It
>It won't because a cellular host /e.g. 3gpp) is alone on its link.
On a point-to-point link, there must be at least two nodes...
In this case, one node is the cellular host and the other is
the 3GPP router (GGSN).
The link is the PDP Context. If more than one host is attached
via a cell ph
>
> > BTW: Does 1) include the ability to run e.g. Java applets or
> > other downloadable code?
>
> I think we would clasify it as closed, no applets or
> downloadable code.
Hmmm. I think you've excluded a large number (the majority) of the
kinds of devices that you'd like to be giving guid
> > > What happens when that host receives an NS message?
> >
> > It won't because a cellular host /e.g. 3gpp) is alone on its link.
>
> I don't see why this should necessarily be the case, unless
> 3gpp is trying to treat IPv6 as a link layer.
No, it's just a normal point-to-point link
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 05, 2002 4:15 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Should connecting to the Internet be Optional?
>
>
> Hi Phil,
>
> > May
> > What happens when that host receives an NS message?
>
> It won't because a cellular host /e.g. 3gpp) is alone on its link.
I don't see why this should necessarily be the case, unless
3gpp is trying to treat IPv6 as a link layer.
what if there are one or more hosts connected to the data i
Sure.
"For the purposes of this document, a cellular host is considered to
be a terminal that uses an air interface to connect to a cellular
access network (i.e. GPRS, UMTS, CDMA2000) in order to provide IPv6
connectivity to an IP network."
As others have pointed out it's hard to be
>
> I don't think we should. It just starts us down that
> slippery slope of creating new "foo hosts" requirements docs.
> Your following arguments are reason enough to avoid this path.
Agree we shouldn't.
>
> >
> > If so, how can we prevent the two most likely bad outcomes:
> >
> >
Margaret,
Margaret Wasserman wrote:
>
> Before folks go and do a lot of additional work to update
> draft-ietf-ipv6-cellular-host-00.txt based on our discussions,
> I think we have to answer a fundamental question:
>
> Should the WG publish an informational RFC detailing the IPv6
> requirements
> However, it is expected for ND to receive "advice" from other layers
> regarding the "reachability" of another host -- so it would be
> great if the L2 mechanism gave ongoing advice to IPv6 regarding
> the reachability of the router, which would result in suppressing
> IPv6 NS messages.
Ye
I agree with Robert on this...
>That is, the proper place to make this kind of argument / statement, would
>be in a draft with a title something like "IPv6 over 3GPP network links",
>which would look very much like the "IPv6 over foobar" drafts/rfcs that
>now abound.
Many of the specific techni
Hi John,
>This router
>most likely will not be a final destination for the host's traffic.
>Additionally, due to special characteristics of the cellular link,
>lower layer connectivity information should make it unnecessary to
>track the reachability of the router.
We h
Before folks go and do a lot of additional work to update
draft-ietf-ipv6-cellular-host-00.txt based on our discussions,
I think we have to answer a fundamental question:
Should the WG publish an informational RFC detailing the IPv6
requirements for cellular hosts?
If so, how can we prevent the
Richard,
Preliminary comments: If I read it correctly, all the RA extensions are based on
destination IPv6 address. I can see several situations where it might be useful to
have some RA extensions based on the source address as well, which would create some
kind of a policy routing in the host
> > No. The terminal (phone) doesn't need to act as a router to allow
> > for multiple devices behind it to connect to the cellular
> interface.
> > You could eventually have multiple serial connections to
> the terminal
> > each having its own corresponding air interface
> connection.
> No. The terminal (phone) doesn't need to act as a router to allow
> for multiple devices behind it to connect to the cellular interface.
> You could eventually have multiple serial connections to the terminal
> each having its own corresponding air interface connection. So it can
> act as a host
> these sound like useful categories. however, for categories #1 and #2
> there would need to be different requirements depending on whether
> or not the device had an external interface to which one or more other
> IPv6 hosts could be attached.
>
> JWi: Thanks for your opinion! This is a releva
> > > true enough. but then you need the phone to act like an
> IPv6 router.
> >
> > But what about if PPP is used?
>
> I don't immediately see how the choice of link-level
> protocol changes this.
>
> Keith
>
> p.s. assuming this is a serial interface, PPP framing might
> be a
Hi!
-Original Message-
From: ext Keith Moore [mailto:[EMAIL PROTECTED]]
Sent: 05 March, 2002 16:06
To: Wiljakka Juha (NMP/Tampere)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Applicability of draft-ietf-ipv6-cellular-host-00.txt
> At least these "cellular host categories" c
> At least these "cellular host categories" can be imagined:
>
> 1) "Closed system" basic 2.5G / 3G terminal typically with fixed
> applications and software. Examples of such devices could be Nokia
> 8310, Ericsson T65, Motorola Timeport 280, ... Usually these
> terminals have a very compact
> > true enough. but then you need the phone to act like an IPv6 router.
>
> But what about if PPP is used?
I don't immediately see how the choice of link-level protocol changes this.
Keith
p.s. assuming this is a serial interface, PPP framing might be a reasonable
choice. But PPP authentica
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : Domain Name Auto-Registration for Plugged-in IPv6
Nodes
Author(s) : H. Kitamura
Filename: draft-kitamura-ipv6-name-auto-reg-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.
Title : Default Router Preferences and More-Specific Routes
Author(s) : R. Draves
Filename
Hi Erik,
> > 1) Closed 'phone' with no additional external interfaces,
> >limited software & upgradability.
> > 2) PDA / phone, small device, small configuration ability,
> >some ability to run extra applications, additional
> >interfaces possible.
> > 3) PCMC
> Parsing through your comment, are you suggesting that be better clarify
> some instances, such as
>
> 1) Closed 'phone' with no additional external interfaces,
> limited software & upgradability.
> 2) PDA / phone, small device, small configuration ability,
> some
Hi Markku,
> > This leads me to think that IPv6 MUST support either stateless or
> > stateful, but stateless is not mandatory.
>
> This seems quite warped, as stateless is much simpler than stateful
> (at least with PPP6, which can negotiate ID part). And probably every
> existing IPv6 stack h
> X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to
>[EMAIL PROTECTED] using -f
> From: [EMAIL PROTECTED]
>
> This leads me to think that IPv6 MUST support either stateless or
> stateful, but stateless is not mandatory.
This seems quite warped, as stateless is much simpler
Hi Tony,
> The document is fundamentally flawed because it is focused on a target
> product, the micro-3G handset. If it gets rewritten to focus on unique
> exceptions for the cellular air-link that are strictly about
> addressing the problems that arise from its characteristics, it MAY be
> wo
Hi Phil,
> Maybe we should call it the cellular interfaces draft
I think that would not be sufficient. Currently, there is no
IPv6 hosts document. If there were one, this discussion would
be shorter. I would suggest that some sort of hosts document
is needed - it will be a big problem if
Hi Margaret,
> However, I think that RFC 2462 should be a MUST for all IPv6 nodes.
2462 states in the introduction:
IPv6 defines both a stateful and stateless address autoconfiguration
mechanism. Stateless autoconfiguration requires no manual
configuration of hosts, minimal (if any) co
Hi, Erik and the others!
Let me suggest the following - before we can draw good conclusions, we need to better
define what we are actually talking about.
At least these "cellular host categories" can be imagined:
1) "Closed system" basic 2.5G / 3G terminal typically with fixed applications a
On Mon, 4 Mar 2002, Tony Hain wrote:
(Half-) seriously.. I think connecting to the Internet MAY be optional.
I discussed in lcna-minreq thread; I think that if a node like that can
not implement IPSEC or security in general, it MUST NOT have a global
address. Under some cornercases, link-local
Hi Erik,
> I think part of the questions are around the applicability of
> the document. The document doesn't seem to constrain this very
> much:
>
> For the purposes of this document, a cellular host is considered to
> be a terminal that uses an air interface to connect to a cellular
> a
Hi Margaret,
> I understand the argument for why you would not need to
> use DAD.
>
> However, you would need to use NS and NA messages to
> establish two-way reachability to the router, before
> sending other IP packets to (or through) that router.
> This is the basic neighbor discovery mec
72 matches
Mail list logo
