Subject: RE: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?]

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

Andrew,

Can we keep 3gpp architecture discussions OFF this list?

What we are talking about is an IPv6 host with a point-to-point
link to a router. They run PPP and the router delegates
a global prefix to the host. The router doesn't configure
any address on the delegated prefix and it supports NS/NAs.

I know the 3gpp specs well and that's the scenario that is portrayed.
It's not an abnormal IPv6 scenario as is clear from above, so
there's no "half right" stuff. Statements like yours just try
to take away value from the effort that 3gpp and ietf have done so
far to get 3gpp in line with IPv6. And they're not succeeding
either.

/Karim

 > -----Original Message-----
 > From: Delecki Andrew-Y10658 [mailto:[email-masked]]
 > Sent: den 7 mars 2002 01:11
 > To: 'Hesham Soliman (ERA)'; 'Charles E. Perkins'; Karim 
 > El-Malki (ERA)
 > Cc: [email-masked]
 > Subject: RE: Should DAD be optional?
 > [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?]
 > Importance: High
 > 
 > 
 > Dear Hesham,
 > 
 > This what is in current 3GPP specifications, is not 
 > necessarily the "right thing".
 > 
 > Recommendation shall include the right network topology and 
 > IPv6 mechanism, not deal with system, which is only "half" right.
 > 
 > Andrew D.
 > 
 > Motorola 
 > 
 > -----Original Message-----
 > From: Hesham Soliman (ERA) [mailto:[email-masked]]
 > Sent: Wednesday, March 06, 2002 3:24 PM
 > To: 'Charles E. Perkins'; Karim El-Malki (ERA)
 > Cc: [email-masked]
 > Subject: RE: Should DAD be optional?
 > [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?]
 > 
 > 
 > Hi Charlie
 > 
 > I finally read the thread.
 >   
 >   > > I agree that it would be good to see some guidelines in an
 >   > > informational doc. However I disagree on the title change to
 >   > > IPv6 over cellular/3g. That is a different spec which we should
 >   > > also work on.
 >   > 
 >   > It is possible to design "cellular" systems where the
 >   > 3GPP/PDP address assignment is completely replaced by
 >   > localized, stateless methods.  The way that addresses
 >   > are assigned is not related to bandwidth, nor even to
 >   > essential authorization issues.  It's an artifact of
 >   > near-compatibility with existing 2.5G layouts.  GGSN
 >   > does not NECESSARILY need to control this process.
 >   > 
 >  
 > => That's fine, but we have to deal with what *is*
 > right now and not what *may come*. 
 > There are people that want to roll out systems with
 > IPv6 support today, R&D will no doubt improve
 > things, but in this draft we need to deal with
 > the current specs.
 > 
 > 
 > 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]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Thu, 07 Mar 2002 19:35:22 +0700

Date:        Thu, 7 Mar 2002 11:59:44 +0100 
    From:        "Karim El-Malki (ERA)" <[email-masked]>
    Message-ID:  <795A014AF92DD21182AF0008C7A404320DFBEFE8@esealnt117>

  | Can we keep 3gpp architecture discussions OFF this list?

As far as it goes, probably yes - but as long as you keep referring
to peculiarities of it, to justify other decisions, then no...

The problem here is that there's no spec for IPv6 over those links.
Define one of those first, until that's done, attempting to define
host requirements for hosts connected to such a link is straight out
silly - how can anyone run IPv6 over any random link in any kind of
standardised way, when there's no existing spec on how to do that?

It is frightening to think that people seem to be contemplating actual
implementations of this, with no spec at all to base their implementation
on.   This needs to be fixed, and quickly.

  | What we are talking about is an IPv6 host with a point-to-point
  | link to a router. They run PPP and the router delegates
  | a global prefix to the host. The router doesn't configure
  | any address on the delegated prefix and it supports NS/NAs.

It sounds as if what you're really describing is an "unnumbered" link.
(From the global point of view anyway) - the delegated prefix would be
for the host (terminal, phone, ...) to use as it sees fit?

Is that how it always *must* be done?   If so, that's what the IPv6 over
whatever doc should be saying (along with the appropriate justification).

But in any case, any link is going to have the link local prefix on it,
and on that one, the router is supposed to go and configure the "any routers"
anycast address, aside from a unicast address for itself usually - there's
absolutely no reason why it shouldn't - regardless of any prefix length
that might be used for a global prefix on the link (were there to be one),
the link local is always a /64 - so there really are plenty of addresses
there for there to be one for the host/terminal/phone/... and one for the
router.   Not allowing the router to have a link local address on the
link would need very good justification, as it would break all kinds of
assumptions made everywhere else.

There absolutely needs to be a description of how to run IPv6 over any
link type it is intended to run over - for some links this spec is close
to trivial, for others it is complex - but it needs to exist for all.

If it existed here, and you were attempting to write a "guidelines for
implementors of 3GPP hosts" then most of the discussion that's been held
here recently would never have happened (some of it would doubtless have
been held in the context of the IPv6 over foo document - but in that context
some of the arguments, from both sides, simply make no sense).

kre