Subject: RE: Cellular host draft - where we are and suggestions for moving forward.

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Thu, 7 Mar 2002 20:52:27 +0100

Tony,

The right thing is to consider a basic host first, which is
what the cellular hosts work is about. That is simply because
3gpp will make widespread deployment of v6 hosts in the near term.
If we delay things further we're just going to end up with 3gpp
people going off and doing their own thing as Jim pointed out.
I hope we can make sure this doesn't happen. You want us to
consider a router on the other end of a cellular link when we
don't even have a minimum host requirements document. How can that
make sense? Let's do one thing at a time, hosts first, and ensure
that we'll have compatibility.

In any case, I can't see that we have cut out any future development
based on having routers there even if we disable DAD (on the
cellular link ONLY). Anyway this is not the important issue right
now since the problem we are facing is widespread host deployment.

/Karim

 > -----Original Message-----
 > From: Tony Hain [mailto:[email-masked]]
 > Sent: den 7 mars 2002 20:10
 > To: Hesham Soliman (ERA); [email-masked]
 > Subject: RE: Cellular host draft - where we are and suggestions for
 > moving forward.
 > 
 > 
 > Hesham,
 > 
 > I appreciate where you are trying to go, but I think you are 
 > still being
 > blinded to issues because the focus is to centric on *host*. 
 > Yes people
 > are motivated to worry about that problem first, but making design
 > assumptions based on the mobile device on the end of an 
 > air-link being
 > limited to a host will cause problems. The current logic 
 > appears to be
 > 'we don't want to do DAD, so define the link in terms of a 
 > host so it is
 > unnecessary, then worry about a router later'. The host perspective
 > should always be a subset of the demands of a link technology, so
 > starting there will only assure that the link can never be 
 > used outside
 > that scope. A group that is so focused on overhead of bits on the
 > air-link should really be concerned about the impact of 
 > forcing a router
 > to use IPv6 over IPv6 tunneling to get a reasonable service over it.
 > 
 > As a specific comment to your note, rather than assume that
 > implementations will end up with an MTU of 1280, simply 
 > state that the
 > interface MTU == 1280. In any case the infrastructure components will
 > have to respond appropriately to nodes that implement PMTU, so don't
 > assume that it won't happen just because it is not required 
 > for devices
 > that are directly attached.
 > 
 > Tony
 > 
 > 
 > 
 > > -----Original Message-----
 > > From: [email-masked]
 > > [mailto:[email-masked]]On Behalf Of Hesham
 > > Soliman (ERA)
 > > Sent: Thursday, March 07, 2002 9:58 AM
 > > To: [email-masked]
 > > Subject: Cellular host draft - where we are and 
 > suggestions for moving
 > > forward.
 > >
 > >
 > > Hi all,
 > >
 > > I think we're having a pretty useful discussion
 > > about this draft which has highlighted a number
 > > of issues that need to be addressed. This
 > > is an attempt to summarise the issues that were
 > > discussed and see if we can find a way forward.
 > >
 > > Please note, this is not to suggest 1, 2 or 3
 > > drafts ...etc, this is an attempt to resolve the
 > > technical issues first, editing them in documents
 > > is another issue that can be handled after we
 > > agree on what we're going to put in such documents.
 > >
 > > Before I list the issues and responses, I'd like
 > > to highlight an important point: This draft attempts
 > > to do 2 things:
 > >
 > > - Define the behaviour of a cellular host residing
 > > on a cellular link (in this case we only know of
 > > 3GPP networks because no one else has defined
 > > the use of IPv6 in their specific link)
 > >
 > > - List the host implementation requirements in
 > > a cellular network (not only 3GPP) based on
 > > the common characteristics of these networks
 > > (p2p channels, BW, resilience over the air
 > > interface ...etc)
 > >
 > > Perhaps the two points above can be separated
 > > in 2 documents, but I'm really interested in
 > > getting an agreement on the technical issues
 > > _first_. Editorial issues are secondary here.
 > >
 > > So the main issues that were brought up so far are
 > > (please let me know if I missed a major issue):
 > >
 > > Issue: What is a cellular host ?
 > >
 > > Suggestion: A cellular host is _any_ host that
 > > has a cellular interface. This would include
 > > low end devices like basic phones and high
 > > end devices like laptops. Low end devices will
 > > generally follow the behavioural aspects of
 > > the draft as well as the minimum implementation
 > > requirements, due to the lack of computing capacity.
 > > However, high end devices will implement whatever
 > > they want, but MUST follow the required behaviour
 > > _on_the_cellular_ interface.
 > > Please note that when it comes to implementation
 > > requirements, the draft never suggests that
 > > a standard MUST NOT be implemented, so everyone
 > > is free to implement more. The draft aims at
 > > the minimum, interoperable implementation.
 > >
 > > Issue: The use of the word 'terminal' is
 > > confusing.
 > >
 > > Suggestion: replace 'terminal' with Host.
 > > This was a mistake anyway.
 > >
 > > Issue: Should DAD be disallowed
 > >
 > > Answer: DAD for the general cellualar
 > > case is allowed in the draft.
 > > In the 3GPP-sepcific case, DAD is not needed because:
 > >
 > > - The link is p2p
 > >
 > > - The link-local address is given to the
 > >   cellular host (it can't reject it).
 > >
 > > - A /64 is given to the cellular host _only_
 > >
 > > - The GGSN will ensure the uniqueness of llA
 > > and will not use the host's /64 to configure
 > > any of its global addresses. The same goes
 > > for site-local if used.
 > >
 > > So DAD is not needed. This is analogous to
 > > a design decision to always assume an MTU
 > > of 1280, PMTU implementation becomes superfluous
 > > if the host will _never_ send a packet larger
 > > than 1280.
 > > I think we should close this issue unless someone
 > > points out a flaw above.
 > >
 > > Issue: Should IPsec be mandated?
 > >
 > > Suggestion: We should mandate AH and ESP for
 > > all hosts, following RFC2460.
 > >
 > > Issue: Should ND be mandated?
 > >
 > > Answer: ND is mandated in the draft.
 > > Certain options are not mandated on cellualar
 > > links (like LLA suboption) because it's not
 > > relevant. NUD is a MAY because there are
 > > other ways of detecting reachability in
 > > these links. If multiple default routers exist
 > > RSs and RAs will detect the failure of one
 > > of those routers.
 > >
 > > Issue: Stateless address autoconfig (2462)
 > > allowed?
 > >
 > > Answer: Yes it's allowed for the general
 > > cellualr case. However for the 3GPP case
 > > stateless address allocation works differently
 > > from RFC2462 (and does not break 3041), so
 > > come parts of RFC2462 are not relevant
 > > (the DAD part again!)
 > >
 > > Comments so far? Are these suggestions/answers
 > > accepatable?
 > >
 > > It took me 2.5 hours to write this email because
 > > of my wonderful mail server, so I probably
 > > won't be able to give quick responses.
 > >
 > > Hesham
 > > 
 > --------------------------------------------------------------------
 > > 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-masked]
 > > 
 > --------------------------------------------------------------------
 > 
 > --------------------------------------------------------------------
 > 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-masked]
 > --------------------------------------------------------------------
 > 
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Mar 2002 13:02:45 -0800

> 3gpp will make widespread deployment of v6 hosts in the near term.

That is exactly why it is critical that this be done right the first
time. Once a widespread deployment happens it will be impossible to
change.

> people going off and doing their own thing as Jim pointed out.

Threatening to go away and do the wrong thing as a justification to do
the wrong thing here is a waste of time.

> that we'll have compatibility.

I have been very consistent in that I want you to describe the
characteristics of the link. The device on the end could be either a
host or router, but the current focus on limited capability hosts is
preventing progress. The micro-handset *IS NOT SPECIAL*, so just get
over it. What you need is a standard way of using a link that has
different characteristics than other link technologies already defined.

> now since the problem we are facing is widespread host deployment.

You are talking about product design issues, not standards development
issues. The standards issue is that we need to describe the
characteristics of a specific air-link technology so it can be used in a
consistent manner with other link technologies across all IPv6 capable
hosts AND routers. The longer people persist on trying to solve day-job
problems by inisiting on solving the limited case first, the longer it
will take to make any progress.

I am not against making progress on a document that can be used for 3G
host deployments. I just can't see any real need to special case this
and limit the long term potential of the link just because some people
thought time-to-market was more important than doing it right.

Tony