Subject: RE: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt

From: "Riegel, Maximilian" <[email-masked]>
Date: Fri, 20 Oct 2006 08:23:47 +0200

See inline

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Soininen Jonne (Nokia-NET/Espoo)
> Sent: Friday, October 20, 2006 12:21 AM
> To: ext Alexandru Petrescu; [email-masked]
> Cc: [email-masked]
> Subject: Re: [16ng] Re: I-D 
> ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
> 
> Alex,
> 
> The default allocation policy from the RIRs is /32. So, from 
> an RIR you
> would get always at least /32. If you use addresses from your upstream
> provider how much you get is up to the contract between you 
> and the upstream
> operator.
> ...

> In addition, if some operator would really like to give just /128 per
> mobile, they can always run PPPoE over the ETH CS.

Why PPPoE over ETH CS? ETH CS provides the shared link model of Ethernet
leading to /128 per mobile.

Bye
Max

> I feel like going in circles here. So, I think I'll just stop now.
> 
> Cheers,
> 
> Jonne. 
> 
> 
> On 10/20/06 12:47 AM, "ext Alexandru Petrescu"
> <[email-masked]> wrote:
> 
> > [email-masked] wrote:
> >> Alex,
> >> 
> >>> -----Original Message----- From: Alexandru Petrescu
> >>> [mailto:[email-masked]] Sent: 19. lokakuuta 2006
> >>> 22:49 To: Korhonen, Jouni /TeliaSonera Finland Oyj Cc:
> >>> [email-masked]; [email-masked] Subject: Re:
> >>> [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
> >>> 
> >>> Hi Jouni.. snip-snap heh :-)
> >>> 
> >>> [email-masked] wrote:
> >>>> Hi Alex,
> >>>> 
> >>>> 
> >>>> [snip-snap]
> >>>> 
> >>>>> Let me ask this then: a 3GPP commercial operator giving /64
> >>>>> prefixes to mobiles - does it ensure their mobiles are
> >>>>> reachable from the IPv6 Internet?
> >>>> No.. why should it? This falls into operators' or possible
> >>> customers'
> >>>> deployment decisions.
> >>> Right, and if all customers needed to connect to the IPv6 Internet
> >>>  (and all ready to pay for that) the operator couldn't probably
> >>> technically keep up with the demand, because it had not 
> enough IPv6
> >>>  addresses (it gave a /48 to each mobile).
> >> 
> >> Hmm.. where did this /48 came into picture? Why should I give a
> >> mobile node /48? I could give a customer (e.g. corporate, virtual
> >> operator, etc) using our cellular network a /48 and then 
> he could do
> >>  whatever he wants with that block..
> > 
> > Let's say I'm that virtual operator and I get a /48 from 
> you.  How many
> > mobiles can I accomodate if I give each mobile a prefix?  
> Probably no
> > more than 65535.
> > 
> > Let's say you are a real operator and get a /48 from a RIR. 
>  How many
> > mobiles can you accomodate with a prefix-per-mobile?  
> Probably no more
> > than 65535.
> > 
> > I think that's how I came up with the /48 figure.
> > 
> > Why only 65535 mobiles if a /48 prefix?  Because the other 
> boundary is
> > 64.  Which makes for 64-48 is 16.  Two to 16 is 65536.  I hope I
> > had that right.
> > 
> > What if I want to accomodate 1 million mobiles?  I'll 
> probably need 20
> > /48 prefixes like that from you.  Or you need 20 /48 
> prefixes like that
> > to give only to me.  You may say it's feasible.
> > 
> > But.
> > 
> > Look how many mobiles you could accomodate if you could 
> share one /64
> > prefix among the mobiles.  You could have 2^64 mobiles only with one
> > such /64 prefix.  All this space risks being wasted.
> > 
> >>> I think that an operator planning its network should know in
> >>> advance that if it distributes a /48 to each mobile user then it
> >>> will face the risk of not having enough of those /48s.
> >> 
> >> I think operators survived this far are capable of planning their
> >> networks.
> > 
> > YEs.  I do not intend to make this any personal.  I bear in 
> mind that we
> > participate as individuals here.  I do not take your 
> participation as
> > you speaking for your employer.  I hope you don't either.
> > 
> >>> A closed IPv6 network, within one operator services and 
> users, is a
> >>>  different thing indeed.  But then, these operators also 
> wonder why
> >>>  not continue use non-routable NAT IPv4 addresses?  IPv4 does the
> >>> trick as IPv6 in most respects and functionalities.
> >> 
> >> Well.. to be honest, for many operators there are no 
> pressing reasons
> >>  to migrate to IPv6.
> > 
> > That's a good remark.
> > 
> > Alex
> 
> -- 
> Jonne Soininen
> Nokia
> 
> Tel: +358 40 527 46 34
> E-mail: [email-masked]
> 
> 
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Oct 2006 12:46:36 +0200

Jonne, thanks again for another pointer:  RFC3177 "IAB/IESG
Recommendations on IPv6 Address Allocations to Sites" and its proposed
undergoing update draft-narten-ipv6-3177bis-48boundary-02.txt "IPv6
Address Allocation to End Sites" don't seem to make the point I _think_
you may be trying to convey.

Soininen Jonne (Nokia-NET/Espoo) wrote:
> Alex,
> 
> The default allocation policy from the RIRs is /32. So, from an RIR 
> you would get always at least /32. If you use addresses from your 
> upstream provider how much you get is up to the contract between you 
> and the upstream operator.

RFC3177 and the proposed update seem to indicate that currently /48 is
recommended and probably the recommendation should change to e.g. /56.

RFC3177 contains not the string '/32'.

> In addition, you can take a look at RFC3177, if you want to know what
>  IESG and IAB recommend as the address allocation for sites - I think
>  the /64 applies pretty well for Mobile hosts as the minimum.

RFC3177 seems to say that /128 is allocated when it is known that only
one device is connected.

> (I have nothing against an operator allocation a shorter prefix than 
> /64 for a mobile  - the prefix-per-mobile link-model allows that).

Ok.

> Like I tried to say, there was a consensus call on the link-model. 
> One of the reasons we decided that model was the technical difficulty
>  to make the shared prefix model to work. You should come up with an 
> argument that would show that the decision we made was wrong. I 
> haven't seen one, yet.
> 
> If you think this is an important issue for you, you most probably 
> should start defining the solutions for making the shared model to 
> work as the recommendation says. The link prefix-per-mobile model 
> does not preclude of adding a new mechanism in the future if needed.

Thanks, that is good to know.

Alex
>From [email-masked] Fri Oct 20 23:24:38 2006
Date: Fri, 20 Oct 2006 13:19:12 +0300
From: Jari Arkko <[email-masked]>
To: ext Alexandru Petrescu <[email-masked]>
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
cc: [email-masked]
cc: "Soininen Jonne \(Nokia-NET/Espoo\)" <[email-masked]>

Let me just remind everyone that we are in the IP over
802.16 working group. Are the specifics of the 3GPP
design relevant for our discussion here?

And: lets focus on the current ongoing consensus calls
on the documents, not rehashing discussions from
the past ones. I have not yet seen enough reviews
of the IPv6CS document.

--Jari

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Fri, 20 Oct 2006 16:16:42 +0300

Alex,

I said I would not write anymore, but it seems that I already now break my
own rule. However, to avoid greater confusion I would like to comment:

> you may be trying to convey.

I believe it is clearly stated in RFC3177. The Narten draft is is "just an
update" on the /48 boundary. I think the /64 recommendation is pretty clear
there. 

I understand that this may be difficult for a new reader and for someone
that doesn't necessarily know the history. IETF specs don't always clearly
state the history and the justification for an architectural choice. It was
at least for me difficult back when RFC3314 was written.

> RFC3177 contains not the string '/32'.

Perhaps this is because RFC3177 does not define address allocation policies
for the RIRs. Please, check the allocation policies from the RIRs web sites.

> RFC3177 seems to say that /128 is allocated when it is known that only

Do you know there is only one device behind the mobile link? How can you be
sure? What if there are many? Basically then you have to start to apply IPv6
NAT. I think that is a clear no-no.

Anyways, I guess we have now beaten this horse to death. At least I have.

Cheers,

Jonne.
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34