APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists global-v6 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GLOBAL-V6] Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt



Hi Marcelo,

 | > Many of home routers sold in Japan is designed and build
 | > to associate with an ISP's service operational scheme.
 | > Currently, a home router receiving /48 from the ISP block
 | > and assigned a /64 out of it automatically
 | 
 | How does the router obtains the /48? is this automatic? does it uses  
 | DHCP prefix option?

>From the address assignment view point, many ISPs in Japan use the
DHCPv6 prefix option for residential users. So, TECHNICALLY, changing
the assignment size may not be so hard for ISPs.

However there may be some cases that ISPs have to check the DHCPv6
client devices' behavior, the independency of the /48 prefix size (/64
prefix selection, filtering function, and so on).

 | > If the assignment size gets various, more overhead functionality
 | > needs to be implemented into the home router to set the appropriate
 | > assignemnt size user by user, and/or ISP needs to decide its size
 | > user by user (since the size of assignment under /48 is determined
 | > by ISPs).
 | 
 | AFAIU, so far the proposal is to have two prefix lengths /48 for big  
 | end sites and /56 for smaller sites. I am not sure how much more  
 | complexity this would add...
 | I mean, automatic prefix delegation using dhcp prefix option would  
 | support this transparently.

This may not be the IETF issue, but from the ISPs' service view point,
changing the prefix size has a impact to existing service spec (of
course, the spec includes the price of the service. Should ISPs
provide existing /48 service and following /56 service as same price?
Don't customers complain this?).

And mixing the different size prefix may increase the cost of the
address management (but this may not be a big problem as you said).

--
Tomohiro Fujisaki