A prefix of less than 64 bits would be useful when having a small Public
Internet -> Ethernet -> 6LowPAN network. Public prefix's are normally
allocated in 64 or 48 bit sizes. When I set up a network like this, I
needed a public /48 instead of a /64 so that I could have one /64 for
the Ethernet and one for the 6LowPAN. In my case, the Ethernet was only
used between the edge router and the IPv6 router so just had the address
of these two routers on it.
Setting up a network in this way would force the use of the 16 bit
short addresses when using the public Internet. However, these
addresses compress better than EUI 64 addresses and so may be a better
choice anyway.
To avoid confusion between the EUI 64 derived addresses and the short
address, it may be better to use a /40 (or /48) rather than a /17
addressing scheme. We could then keep the pseudo 48 address with the
::xxff:fexx: as part of the prefix and so keep the advantage of easily
identifying EUI64 or short addresses.
I am therefore in favour of the second proposal, using a /17. However,
if there are reasons why it would not be possible to use the spare bits
in this way then I prefer the first proposal of a /64 because it is simpler.
Daniel.
Jonathan Hui wrote:
In an effort to update 6lowpan-hc so that we can quickly move it back
into WGLC, I'd like to close on this issue by the end of the week.
Please provide your feedback.
--
Jonathan Hui
On Mar 29, 2010, at 8:10 AM, 6lowpan issue tracker wrote:
#65: Deriving IIDs from Short Addresses
--------------------------------+-------------------------------------------
Reporter: j...@… | Owner: j...@…
Type: defect | Status: new
Priority: major | Milestone:
Component: hc | Version:
Severity: Active WG Document | Keywords:
--------------------------------+-------------------------------------------
One of the issues raised on the ML and in Anaheim is the issue of
deriving
IIDs from IEEE 802.15.4 short addresses. There was general consensus
that
the PAN ID should never be included in the IID. As such, I think we now
have the following two options:
1) Maintain the RFC 4944 translation (short address -> ethernet
address ->
64-bit IID). Generated IIDs will be 64 bits in length and of the form
(0000:00ff:fe00:xxxx), where xxxx is the short address.
2) Update RFC 4944 translation to (short address -> 17-bit IID).
Generated IIDs will be 17 bits in length and of the form
(0000:0000:0001:xxxx), where xxxx is the short address.
The primary difference between the two options are the lengths of
prefixes
that may be used to generate global addresses. Option 1 says that
different PANs must be assigned unique 64-bit prefixes. Option 2 says
that different PANs must be assigned unique 111-bit prefixes, but that
multiple PANs may utilize the same 64-bit prefix.
I am comfortable with either option, but we need to agree on one that is
well-defined. So which would people prefer? If you have no preference,
please provide that feedback as well.
--
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/65>
6lowpan <http://tools.ietf.org/6lowpan/>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
--
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 Registered In England
http://www.jennic.com
__________________________________________________
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
